Gui implementation in extensible framework

Discussion in 'Java' started by Twisted, Mar 29, 2006.

  1. Twisted

    Twisted Guest

    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?

    --
    I am the terror that flaps in the net!
    I am the circular dependencies that confound and confuse!
    I am TWISTED!
     
    Twisted, Mar 29, 2006
    #1
    1. Advertising

  2. Twisted

    Oliver Wong Guest

    "Twisted" <> wrote in message
    news:...
    > 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
     
    Oliver Wong, Mar 29, 2006
    #2
    1. Advertising

  3. Twisted

    Twisted Guest

    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...

    --
    I am the terror that flaps in the net!
    I am the expensive proprietary software for which you can find no
    usable free alternatives!
    I am TWISTED!
     
    Twisted, Mar 30, 2006
    #3
  4. Twisted

    Oliver Wong Guest

    "Twisted" <> wrote in message
    news:...
    > 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
     
    Oliver Wong, Mar 30, 2006
    #4
  5. Twisted

    Twisted Guest

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

    --
    I am the terror that flaps in the net!
    I am the mosquito that bites a spot you can't reach!
    I am TWISTED!
     
    Twisted, Mar 31, 2006
    #5
  6. Twisted

    Oliver Wong Guest

    "Twisted" <> wrote in message
    news:...
    > 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
     
    Oliver Wong, Mar 31, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lucas Tam

    Building an Extensible Web Framework

    Lucas Tam, Oct 12, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    376
    Lucas Tam
    Oct 13, 2005
  2. Ravi Shankar
    Replies:
    0
    Views:
    360
    Ravi Shankar
    Jan 4, 2004
  3. -
    Replies:
    1
    Views:
    346
    Thomas Weidenfeller
    Apr 6, 2005
  4. kwatch
    Replies:
    0
    Views:
    113
    kwatch
    May 23, 2007
  5. kwatch
    Replies:
    2
    Views:
    107
    Tom M
    Sep 25, 2007
Loading...

Share This Page