Editor concept materializing..

[Keith Donald]

I'm getting closer to introducing the concept of an Editor; specifically, a visual component within a page area that supports the editing of an object or file (some input.) This is somewhat like a view, but different: multiple editors of the same type can be opened within the editor area on the page (for editing different inputs) (think eclipse when you're opening java files that are tabbed accross the editor area - instead of java files, customer records, for example), while there can only be at most one view of a given type displaying on a page. Editors can be explicitly saved, modified (can be dirty), and are typically backed by a form/form model for editing a domain object.

The first step towards this goal is introducing two interfaces: Dirtyable and Saveable, which the Editor interface will inherit when it is introduced. The next step is to add the ability for the application page to open editors for a particular editor input (say a domain object) and display that within the editor pane area. The framework will track the active editor and if changes have been made, issue a "save reminder' for example when the editor window is closed.

Thoughts? For you Eclipse RCP gurus our design is similiar on purpose: one to facilitate people going between both platforms (ease of learning curve) and secondly because it's just good design. Our niche is we will be a lighter weight implementation built on Spring for configuration, and hopefullly one that's more pluggable with regard to the underlying windowing system.

[cyboc]

I think it's an excellent idea. I hate having to manage that stuff myself. It's nice if you can get those services from a framework.

Perhaps you could extend the idea so that the editors in the editor area (optionally) get their underlying domain object references from a JTree that is beside the editor. This is similar to Eclipse's Package Explorer and Navigator tree views. The framework would manage the communication between the tree and the editor area, automatically updating the tree node display strings upon a change in a corresponding editor. I'm not sure if this is the same idea as TreeCompositeDialogPage; I haven't tried that class out yet.

[steve_smith]

I think its good idea too. BTW, my wife says I have a Dirtyable interface...

[pdbruycker]

About the TreeCompositeDialogPage:

The TreeCompositeDialogPage is an implementation of the CompositeDialogPage. (Another implementation is TabbedDialogPage). It is a way of organizing several DialogPages in one dialog.

If you open the properties of an Owner in the Petclinic sample app, there are two tabs... these come from the TabbedDialogPage.

The TreeCompositeDialogPage shows a tree on the left, containing all the pages (in a hierarchical form), and on the right the pages itself are shown.
(It is built after the Preferences dialog from Eclipse).

Peter

[Keith Donald]

Peter,

That's nice! Perhaps when you get a free bit you could integrate the TreeCompositeDialogPage into petclinic? Maybe we could make which one that is used pluggable, so users could try each out.

[pdbruycker]

I could make a PreferencePage for it, so users can choose which they want to see.

Since I'm working on the preferences api, this could be interesting.

Peter

[adepue]

Keith,
I'm finding that I regularly need ActionCommands which are aware of a currently loaded object. Say, for example, that the user is currently editing some object that contains a list of users and they click the "Delete" button, which happens to have been generated by DeleteUserFromMyObjectCommand.createButton(). The DeleteButton will invoke DeleteUserFromMyObjectCommand, which now has to determine which object is loaded and from there determine which user is selected. I'm guessing that some kind of Editor API is just what I need. In my case, the Editor API must somehow allow Commands to become aware of the object currently being edited. I would prefer one of two solutions: 1) either pass the edited object (or some construct which can access the edited object) as parameter to the Command execution, or 2) provide some kind of editor service API whereby I can query for the currently edited object. My Commands also need to react to editor state change (if some particular state changes in the editor or edited object, then disable the command, for example). If I use private state in my command object (or even in an ActionCommandExecutor), then that makes it difficult (if not impossible) to define the command as singleton in the Spring config - so a solution along these lines is not preferred.
A good temporary solution to my problem would be to provide a "createButton" method in ActionCommand that allows me to pass parameters to the command when the button is pressed. For example:

Map params = new HashMap();
params.put("myObject", myObject);
AbstractButton deleteUserButton = deleteUserCommand.createButton(params);

Then, whenever deleteUserButton is pressed it will execute my command while passing in the specified parameters. This allows different button instances to invoke the command with different parameters (which works in my case, as the only time multiple editors are open is when there are multiple application windows open, thus multiple button instances).

[Keith Donald]

Quick reply, Andy, yes, this is a common requirement.

Take a look at AbstractForm -- it provides some help for this now, notably creating commands allowing you to commit, reset, or revert an actively edited form object. It can also auto-set the active form object based on the value of a selected list index--allowing you to easily delete/change the selected object (specifically via a selectedIndexHolder ValueModel of a editableFormObjectListHolder)

I do have some sample code I can extract out of my app that illustrates the above features nicely. For example, I frequently show -- as part of a single dialog page -- a "summary" form showing a list of objects (say customers), and a "details" form below it. When an item in the summary list is selected, the details form model is auto-updated by its AbstractForm (and the selected object may then be edited by the user.) A Remove command allows for deletion of individual items in the summary list form. A "New Form Object" command resets the details form with a fresh, blank form object to be completed. An "Apply" button below the details form allows for executing the commit command, either updating an existing object or inserting a new object if its a "new form object."

Anyway, I'll see about integrating this in petclinic--AbstractForm was specifically designed to handle the above case with very little hand coding.

One of the challenges we are facing is how the editor concept should merge with our current form concept. I'm thinking a editor is more generic--for example, it could edit anything, like a text document: while a form is geared to managing/manipualting a form with fields. But there is overlap: both can be saved, can become dirty--but can editors be committed? Is commit/revert the same thing as save/cancel? Stuff like that we are sorting out.

Keith