Scott Binegar
Tom Donaldson
Rob Douglas
Niall Gaffney
Sandy Grosvenor
Karla Peterson
Frank Tanner
Rob updated the UML diagram for data sharing and high level packaging for the architecture.
Sandy wrote a description of SEA's apply/reset conept. The e-mail is attached to these minutes as the Appendix
Rob will update UML diagrams as per today's discussion.
Tom will prototype CORBA's use with firewalls to see what options and problems exist.
The APT-AI now has a partial list of requirements that the team is proceeding under. Please see the Requirements Document for more information.
The first part of the meeting was used to discuss Rob's high-level package architecture and interoperability talk. This was a continuation of the discussion from last weeks meeting. The diagram is available off of the APT Web page.
The other primary discussion focused around the requirements for the APT and specifically the requirements for the APT-AI. Since no user group has been yet defined to focus the efforts of APT, it seemed prudent at this time to enumerate some of the requirements which the APT-AI team is working under. These requirements may need to be modified as per a user groups feedback later. However, the APT-AI team is working under the assumption that the items enumerated in the requirements are true. See the Requirements Document for a list of the APT-AI requirements.
The astronomical implemenation of XML call AML will be looked at to determine applicability for the APT project.
For your lunch time reading enjoyment, here's a "non-technical" description of how we do the Apply / Reset in SEA...
?Apply/Reset? Issues/Challenges/Strategies
Review of the Issue:
When a user is ?mucking? around in a dialog. There are two common ways of reacting to the user?s changes: immediately announce the change to each individual field to any and all who care, or let the user make as many changes as they like, but don?t announce the change until the user presses an ?Apply? button (sometimes it?s an OK, or Save label).
Our experience with SEA was initially that people liked the immediatechange, that is right up until processing a change requires some time to execute (most notably involving a call to a server that took some varying amount of time). Then we got requests for supporting the ?Apply? mode.
Initially, we thought that the application as a whole should ?toggle? between immediate or delayed mode. In the evaluation phase the SEA is currently going through, we are discovering that the answer is really that some dialogs are best in a delayed mode, some immediate, and that users want to be able to turn it on/off dialog by dialog.
Complicating factors:
1) In the delayed mode, you have an additional complication: the ?Reset? button, or the ?never mind? feature. This is the ability to make several changes, then turn around and have them all wiped out and the last saved state restored. To support this, you need to keep a separate copy of the original ?state? of your dialog selections or objects so you can return to it.
2) The developer has to assume that part or all of the object being edited in one dialog, may also be currently editted in one or more different dialogs, and the two need to stay in synch with each other.
3) The object may actually be a hierarchy of objects. For example in SEA, an Instrument contains a Detector and a Filter. There are other ?child? objects all of whom may (or not) pass change events to each other.
How SEA does it:
SEA has a parent class ScienceObject which is the central parent class for objects that are part of the datamodel. In this discussion you can assume that ScienceObject has methods that manage the relation between one ScienceObject and any child ScienceObjects, as well as event notifications. I won?t detail them here.
We created a master dialog, ApplyResetModule, that handled the apply / reset feature. Its ?delayed mode? could be turn on or off at an application level, and each existing dialog would adjust accordingly, the ?Apply? and ?Reset? and ?OK? buttons would appear/disappear as appropriate. And handling requests to Apply and Reset. Developers then inherit from ApplyResetModule and need only worry about adding the interface components and interactions for for their specific objects.
The ApplyResetModule has a ?setObject()? method that assigns the object being editted. If the delayed mode is enabled, the module does a ?deep clone? of the inbound object (ie making new copies of the object and its children). The original object remains unchanged, and any outside objects listening to it (or vica versa) are not affected. The cloned object does not have any outside listeners.
The cloned object is then loaded into the dialog and changes the user makes are applied to it (but not the original and the rest of the application is happily ignorant)
When user presses the ?Apply? button, then a ScienceObject level method, on the original object is called with the cloned object as its argument: origObject.replaceObject( clonedObject). The replaceObject method will fire an event to all of the orginal object?s listeners tell them to replace the original object with the new object. For example if object X was listening to object A (and in the ScienceObject hierarchy all parent objects listen to their children) and A was being edited by an ApplyReset dialog, then the dialog is accumulating changes in A? ( originally a deep clone of A)? when Apply is hit, object X would receive a ReplacementEvent telling it to replace A with A?.
For most ScienceObject descendents, this event is processed at the ScienceObject level, so descendents can be oblivious to it. Other objects (most commonly dialogs) listening to A are responsible for knowing how to replace A with A?
The Reset (to restore the state) button is enabled whenever A.equals(A?) . And when pressed simply dumps the old A?, reclones A to a new A? and makes the new A? the actively editted object.
If the Apply/Reset feature is disabled, then the Apply button is hidden and can?t be pressed. And A? instead of being a clone of A is set to A itself. So any changes to A/A? are immediately propogated through the normal propertychange handling to any/all listeners.
Good things about this method:
It makes it easy to turn apply/reset on and off. And developers of new dialogs need only worry about testing the ?immediate? change handling mode. If that works right, then the Apply/Reset delayed update is pretty reliable.
It was about the only way to do this once many dialogs had already been created (as was the case in SEA). We did NOT want to either re-write every dialog, nor have each individual dialog have to be aware of two modes of operation.
Challenges to this method:
Every time a change is made to the structure of an subclass of a ScienceObject, the clone() and equals() methods must be reviewed and re-tested.
Cloning is a hassle, deep cloning can be a real pain as the object references can pretty easily get confused. And endless recursion or endless loops can occur.
Ditto with the equals(). Actually in SEA, rather than rely on .equals() which should check for overall equality of an object?s properties? we instituted in ApplyResetModule, a method objectEquals() ? which is what was used to trigger enable/disable of the Reset button, and would be subclassed in the individual dialogs to compare only the parameters of a pair of objects that was relevant to that dialog. But it must be reviewed, modified and retested each time the dialog is modified.
This system required that we use our own custom SEAPropertyChangeListener which extended from the java.beans.PropertyChangeListener to include the requirement to implement replaceObject() method.
This system is not very intuitive and has never felt very robust. In implementing it, I spent a lot of time tracking down ?lost objects? and long complex hierarchies of event handling. Which are not the easiest of bugs to track down as stepping through the code can be quite cumbersome (and push step-level debuggers to their limits)
Other options:
A recent JavaWorld article describes a simply and perhaps more robust method of obtaining a reliable deep clone()?http://www.javaworld.com/javaworld/javatips/jw-javatip76.html - this could help alleviate the need to constantly re-code/re-test the clone() methods
Instead of trying to clone the entire object, save ?initial? states of the fields in the dialog? then on an Apply, run through the fields, firing propertychanges as appropriate, and on Reset, set the fields back to their ?original state?. This puts more of the Apply/Reset management in individual dialogs, but keeps the overall data model simpler and makes for less apparent ?black magic?.
The delayed mode is the part that adds complexity. If we can set up the change handlers so that there is no ?apparent? slow responders (some fast response system from even a server request). Such as a request that requires a server hit, responds immediately with a ?temporary? answer, and then can come back later with the ?real? answer. And if we have a mechanism for objects to know whether they are awaiting ?real? answers or is all caught up, then we might be able to dispense with the delayed mode entirely.
Additional info:
The sea documentation on applyreset is at: http://aaadev.gsfc.nasa.gov/SEA/SEADocumentation/GOV/nasa/gsfc/sea/ApplyRese tModule.html
BTW, You can see all of the SEA javadoc documentation at: http://aaadev.gsfc.nasa.gov/SEA/SEADocumentation It is updated nightly by batch script.