Gui implementation in extensible framework

[Twisted]

OK, here's the rub: there will be document objects, various kinds, with
the potential for more kinds to be introduced in the future by other
coders. (So, there should be an interface or abstract base class.)

These will need gui editability and viewability.

It will be desirable for old gui code to support new document classes.

How to achieve this?

I can see several options, all of which seem to have drawbacks as well
as advantages:

* MVC model, or similar. Each document class has a parallel ui class,
and maybe helper
classes. A UI instance and a document instance are created, and
associated.
Upside: Multiple UI implementations for one document type can be
written and chosen
among.
Downside: Have to create a document object, a compatible UI object,
associate them, and
experience ClassCastExceptions if an incompatible pair arise somehow.
Generally messy
and ugly and type-unsafe.
* Similar, but UI classes "own" document classes -- the UI class acts
as a factory for
document objects (can load, create, etc. them).
Upside: Can again have alternative UI implementations per document
type, and no type
safety issues or ugliness.
Downside: UI implementations must reimplement document factory
methods; or else call
document constructors that receive UI instances as arguments, which
of course may be
called with wrong-type arguments. Also, attaching more than one UI
view to a single
underlying document becomes problematic.
* Document instances provide methods to produce UI instances bound to
the document
instance. Document classes rule, and provide their own viewer/editor
UI.
Upside: Type-safe and can attach more than one UI object to a single
document object.
Downside: Document class author provides "official" UI
implementations, and third party
UI implementations for the same class will be ugly and rickety at
best, and may be
unsafe/nonworking/not possible.

Any experienced application developers know which way to go in this
sort of situation?
Another way of showing it is to show the type hierarchy:
DocInterface --> Doctype1 --> SpecializedDoctype1
JComponent --> DocViewer --> Doctype1Viewer --> SpecializedViewer
JComponent --> DocEditor --> Doctype1Editor --> SpecializedEditor

Problem being you read, say, an ObjectInputStream and cast to a
DocInterface. Then you
want to generate a suitable UI instance. Option 3 above makes it easy,
call a getViewer or
getEditor method specified by the interface, but at the cost of
extensibility (even if you can
make custom viewers that work, you will get the standard one from
getViewer or getEditor).
Options 1 and 2 mean you need to somehow determine if you have a
compatible UI class
at all, and if so what class, and then instantiate it ... ugly as hell
and probably fairly bug-prone.

On the other hand, one could provide DocInterface with a method to
return a Class object
representing an interface all compatible UI implementations would
implement -- Doctype1 say specifies Doctype1EditorInterface. (A given
implementation need not actually provide more than viewing facilities.)
Or better yet, an abstract JComponent subclass implementations should
subclass. This can have a static factory method to provide instances of
Doctype1-author-contrived UI implementations, getEditorInstance and
getViewerInstance. Users could browse a filtered list of alternative
implementations (filtered to show only extenders of the abstract class,
or implementors of the interface) from a list of all the UI classes,
populated via static initializers or something. (The abstract class may
have private static HashSet<Class> foo = null, and the static
initializers have if (foo == null) foo = new HashSet<Class>();
foo.add(class); note latter statement not part of if.)

So far I'm leaning toward option 3, just having the document objects
themselves able to produce instances of appropriate UI objects you can
then stuff into a JPanel. One thing about that that really bugs me
though is that it makes anything that depends on a document class
automatically have associated editor classes as dependencies, even if
it's a batch-mode job meant to do some sort of automated grinding on
document objects rather than an interactive application. And that, of
course, means that said batch job will haul in all of Swing, the AWT,
and God only knows what else (and may fail on headless machines,
machines that don't have a GUI, etc...) Is there a way to avoid a
dependency nightmare without running, instead, into a type-safety
nightmare?

 

[Oliver Wong]

OK, here's the rub: there will be document objects, various kinds, with
the potential for more kinds to be introduced in the future by other
coders. (So, there should be an interface or abstract base class.)

These will need gui editability and viewability.

It will be desirable for old gui code to support new document classes.

How to achieve this?

Might not be a realistic expectation if the documents are intended to be
displayed in ways not anticipated by the "old" GUI classes. For example, if
you initially start with plain text documents, and later want to switch
stylized text, you GUI class has to anticipate this. If you later want to
embed bitmap images, you'd have to have anticipated this too. If those
images can be animated, you had to anticipate that. If the images can be
vector based, can be scripted to respond to mouse over, and have applets
embedded in the document, can represent 3D objects, etc. you'd have to have
anticipated that as well.

Design an GUI class that can handle some set of features, then restrict
your documents to only using features from within that set. Or else have the
GUI ignore features it doesn't understand, but remove the guarantee that the
old GUI can display the new documents (this is the approach HTML takes).

- Oliver

 

[Twisted]

The documents are algorithmically-specified images and videos (think
raytracings, Lissajous figures, etc.); keeping the document classes
from having dependencies on the GUI classes would be nice so that,
e.g., slow to render raytracings can be rendered quietly in a batch
process somewhere; ideally the batch renderer shouldn't have to drag in
gui classes, and thus all of swing and the AWT, which presumably will
happen if the raytrace scene object's class references a gui class via
a getViewer or getEditor type method.

To view, the documents could provide a method to draw themselves upon a
Graphics2D (for a static image or one animation frame of a video), but
that still drags in AWT classes. Perhaps imageio can be used to fairly
cleanly allow output as an image file, for later viewing.

Editing presents the tricky bit. Providing editable algorithm
parameters dialogs or whatever will require knowledge of each specific
document type. I don't see managing it with property sheet type
hashmaps, or bean type declared get/set pairs, not in general. I think
they will have to be able to furnish their own gui controls.

How, though, can I stop any use of a document class then dragging in a
whole wodge of bulky gui classes even if the particular deployment
won't use them? The only method I can think of is to just provide
"getGUIClassName" in an interface, and expect callers to use
Class.forName or similar mechanism to dynamically load the class, deal
with class not found, and pray that handling mismatched pairs of GUI
class and document class isn't too hairy and bug-prone...

Or, I suppose, people could compile batch tools with Jet, which will
apparently drop unused dependencies, so if a getEditorPane method is
never called, the FooEditorPane class isn't loaded, and Swing and AWT
don't get dragged in. But Jet costs money. I want this to be reasonably
usable for free...

 

[Oliver Wong]

The documents are algorithmically-specified images and videos (think
raytracings, Lissajous figures, etc.); keeping the document classes
from having dependencies on the GUI classes would be nice so that,
e.g., slow to render raytracings can be rendered quietly in a batch
process somewhere; ideally the batch renderer shouldn't have to drag in
gui classes, and thus all of swing and the AWT, which presumably will
happen if the raytrace scene object's class references a gui class via
a getViewer or getEditor type method.

To view, the documents could provide a method to draw themselves upon a
Graphics2D (for a static image or one animation frame of a video), but
that still drags in AWT classes. Perhaps imageio can be used to fairly
cleanly allow output as an image file, for later viewing.

Editing presents the tricky bit. Providing editable algorithm
parameters dialogs or whatever will require knowledge of each specific
document type. I don't see managing it with property sheet type
hashmaps, or bean type declared get/set pairs, not in general. I think
they will have to be able to furnish their own gui controls.

How, though, can I stop any use of a document class then dragging in a
whole wodge of bulky gui classes even if the particular deployment
won't use them? The only method I can think of is to just provide
"getGUIClassName" in an interface, and expect callers to use
Class.forName or similar mechanism to dynamically load the class, deal
with class not found, and pray that handling mismatched pairs of GUI
class and document class isn't too hairy and bug-prone...

Or, I suppose, people could compile batch tools with Jet, which will
apparently drop unused dependencies, so if a getEditorPane method is
never called, the FooEditorPane class isn't loaded, and Swing and AWT
don't get dragged in. But Jet costs money. I want this to be reasonably
usable for free...

Have you considered a plugin system so that documents can declare their
content-types, and the program can then "look for" (somehow) editors which
supporting the display of those content-types? Essentially, your program
does almost nothing, but juggle the plugins. All the GUI stuff is handled by
each specific editor-plugin.

- Oliver

 

[Twisted]

Implementing plugins right off the bat sounds like jumping directly
into the deep end to me...

 

[Oliver Wong]

Implementing plugins right off the bat sounds like jumping directly
into the deep end to me...

Well, unless you can think of a better way of implementing this "can
display and edit any future document format that I'll conceive of"
feature...

- Oliver