Thanks for taking the time to explore the JDAF. Please allow us to comment and clarify some concepts:
First, there is nothing stopping one from creating a Session-based application using JDAF. The plethora of adapters, listeners, cutomizers, and integration features for our other products, are explicitly intended for developers to implement the functionlity you describe. We currently only provided one specialized application type, the FileBasedApplication, due to the significant challenges this type of application causes for cross-platform developers. Perhaps this influenced your conception of the product.
To be clear, our initial release provides a foundation from which many different types of applications can be built, and we plan on using JDAF as a platform for releasing other application types. Concerning the characteristics you have outlined, here are some suggestions for acheiving this:
>> 1) A user must sign in / out to establish a session. The current JDAF application lifecycle only considers application opened and closed; it would be neat to also have signed in and signed out.
If the user can only open a single session, the ApplicationLifecycleListener is perfect. It is intended to allow you to provide this very functionality using the applicationOpening() event. If multiple-sessions are appropriate, the DataModelListener can trap each newData() event and provide a log-in there. In either case, you may throw an ApplicationVetoException to have the framework reject the user.
Also, don't get hung up on the Action names. "New" could just as easily be changed to say "New Session". Simply change the name in NewAction or OpenAction and set the criteria that is appropriate for your DataModel. Normally a new DataModel is opened by default so you could even remove these commands from the menus (See MenuBarCustomizer) if there where no need to have different kinds of sessions.
>> 2) Apart from a menu and toolbar the UI typically contains a navigator tailored to the user, Eg. List of their jobs, Pending Claims ect. A session based application tends to be a combination of a session bound navigator and the document approach. The current JDAF application controller is very document centric - building a navigator would be outside the framework which is a shame.
Building a navigator is not outside the framework. It is integrated by the use of the JIDE Docking Framework. You simply set useJideDockingFramework() option to true, and use a DataViewListener to create DockingFrames with the content you desire. For example:
- Code: Select all
application.getApplicationUIManager().setUseJideDockingFramework(true);
application.addDataViewListener(new DataViewAdapter() {
public void dataViewOpening(DataViewEvent e) {
DockableHolder holder = (DockableHolder)e.getWindow();
if(holder.getDockingManager().getFrame("title") == null) {
DockableFrame dockableFrame = new DockableFrame("title");
dockableFrame.setInitMode(DockContext.STATE_FRAMEDOCKED);
dockableFrame.setInitSide(DockContext.DOCK_SIDE_SOUTH);
holder.getDockingManager().addFrame(dockableFrame);
}
});
DataViews are reserved manage the users data, hence you get exactly your prescription for "a combination of a session bound navigator and the document approach".
In addition, FileBasedApplication is actually just a usability interface. The FileHandlingFeature actually is the culprit that adds file-handling to the application (what you are identifying as Document-Centric behavior). Therefore, you could use/subclass GUIApplication, and implement your session-based application. And if you needed to allow the user to access the File system, just plug-in a FileHandlingFeature, to get the best of both worlds.
>> 3) Some displayed data is entirely server controlled, such as the navigator’s data. I guess this would be like a read-only data model. But to go a bit further, rather than just calling updateView(model) every time we refresh the data model it would be neat to have the framework recognise when the data model has been updated with new data with an event to recognise this and only call updateView(mode) when new data is received. Because of JDAF’s document centric nature the using the current DataModel would have unintended consequences for this scenario.
JDAF is Data-Centric not Document-centric. As mentioned above, use the DockingFramework and apply your server logic to a normal Swing component. DataModel is intended for the users data, i.e. that which you would normally place in the docking managers Workspace, not for the DockingFrame contents. Develop docking frames as you have done in the past.
>> it would be neat to have the framework recognise when the data model has been updated
Use a DataModelListener (dataSaving(), dataSaved() events). These are called from application saveData().
Also, concerning attributes of a session-based application there is another more fundamental attribute; they tend to be DB-sourced. If you implement your own DataModel (subclass AbstractDataModel recommended) you can implement how your data is stored to/from a DB as well. See the OpenAction and the idea of "criteia" as parameters to how a DataModel is selected. As "criteria" you could use a query string or even a ResultSet. It pretty wide open.
Hope this helped to clarify some things for you and I hope you will continue to explore JDAF. We are always developing and improving, and to reiterate, more specialized application types are a planned extension to this platform. You comments have helped our focus. Thanks.