SwingXDialog

The design goal of JXDialog was separating the ever-recurring "dialog" functionality from the concrete content, based on my conception of "ever-recurring". Currently, it's poorly documented and incomplete. As it's at the borderline to application-level support, there will not go overly much effort into further evolution - JSR-296 probably already has some answers.

Collaborators

• PresentationModel: drives data and presentation logic of content. Specifically, it provides a applyAction
• ContentView: builds, configures, wires itself to the PM
• Dialog: configures, wires its default actions from the ContentView

Dialog-ness

Basics

• Apply-Button: invoke the content specific apply without doing anything else. Atomics:
  • view.applyAction
• Close-Button: depending on context, this may be labeled differently - close/cancel/no - but means the same thing: go through all the mechanics of closing without applying. Atomics:
  • view.cleanup (f.i. de-registration of listeners, release of bindings. Might be a no-op.)
  • dialog.cleanup (de-registration of listeners, might be a no-op (?) depending on auto-setup on instantiation )
  • dialog.close (overridable - must include dispose ?)
• OK-Button: basically apply + close (validation?)
  • view.applyAction
  • view.cleanup
  • dialog.cleanup
  • dialog.close
• System close - coming in through windowClosing: this must be passed through the close because of the cleanups. Additionally, it should have a hook to allow users to change their minds if the dialog contains any un-applied input
  • without pending changes: same as Close-Button
  • with pending changes: ask user the context dependent "apply now?" with possible answers yes/no/cancel * Yes: same as OK-Button * No: same as Close-Button * Cancel: interrupt closing and go back to dialog

Advanced

• Revert
• Custom Actions

Implementation

The basic idea is to let the view store the appropriate actions in the content's ActionMap and the JXDialog use view supplied actions to customize/replace it's defaults. There are some catches, though (see the example code in the forum thread cited below)

• the dialog.xx are problematic - assuming that the content's actions replace the dialogs, the content must have knowledge about its surrounding - suboptimal
• instead of replacing the action, the dialog could wrap the content supplied action by a delegating action
• nevertheless, the OK-related behaviour is still tricky - it might be triggered programmatically (in the example f.i. by double-clicking into a table row). As the content doesn#t (and must not) know about the dialog, this would be incomplete (triggering the view-ok only)
• could be solved by a view.ok action which broadcasts the actionPerformed (like the BoundAction) and let the dialog wrap a listening action around the view action

At this point the implicit requirements (view actions must broadcast, dialog actions must listen ...) are getting rather complicated. Maybe need a DialogContent abstract class to make explicit? Note: the actions are missing as well ..

TODO: implement the ideas (possible use-case: Richard's example, JGoodies AlbumManager/Editor example, FindPanel, Martin Fowler'sAlbumManager) and commit to incubator

Links

• Using JXDialog
• JSR-296 - Swing Application Framework