Problem editor ideas

I'd like to see the PGProblemEditor module redesigned with the following goals in mind. Please add your own goals or comment on these ones if you like.

Tight integration with the user interface for managing problem source files

The justification for this is that since the editor acts on source files, not on Problem/UserProblem records in the database, we want that to be clear in the UI. Also, tight integration with the source file (er, object) manager would allow us to gracefully do file selection from within the editor, and so on.

The problem editor will still be accessible from the other places where source files are used, like the list of Problems in a Set or Problem.pm, but this would be a secondary link.

Soon the problem source file UI will be Davide Cervone's FileManager module, but in the future it might be replaced by some abstract problem library API frontend (see ProblemLibraryArchitecture).

Independence from display modules like Problem, ProblemSet, etc.

"Wiring" together the editor and Problem.pm has proved to be fragile. It's also bad UI. I propose that instead, a minimal interactive problem processor be integrated into the editor. I envision the user interface consisting perhaps of a tab-based layout with the tabs "Source", "Interactive", and "Hardcopy". Editors could switch among these tabs without having to worry about saving and reloading or dealing with mandatory multiple windows.

This will be especially important as we add the capability to edit additional file types (see below).

This will not be hard to implement once we factor common code out of Problem and GatewayQuiz and clean up Hardcopy. The editor will then be just another user of that code.

Ability to gracefully handle multiple file types.

So far, we've wanted to edit problem source files, header files, text files, and set definition files. The editor can handle some of these things, but it does it in a hacky way. We should set it up so that <nop>PGProblemEditor is replaced with something like FileEditor, which is a factory which produces subclasses of itself appropriate for the file being edited (i.e. FileEditor::PG). Things that could be customized include:

• JavaScript editor widgets for things like "quick reference" popups of functions and variables or buttons for applying tags to an HTML file.
• What previews are available, i.e. "Interactive", "Hardcopy", "Text", "HTML", etc.
• Restricted templates for editing structured data, like set definition files. (Bad example, since these are on their way out, but whatever.)

This would let us gracefully add support for editing new file types without complicating the existing code.

-- Main.SamHathaway - 13 Sep 2004