|The data is passed in a graph of "data" classes. The simplified stateful bean looks like:
| Well, it's sort of like that ;-) Actually, the choice list consists of a list of
| objects with the attributes description and value. The persistence layer used by
| the entity beans detects the change in creditLimit during the update.| > Does your user still see the now stale CreditLimit of 1000 on
| > the Swing form, or do you implement some kind of "Value Messenger"
| > pattern that communicates middle-tier data changes back to
| > the collection of value objects in the Swing thin client?
|
| The stateful session bean returns the saved state back to the client after a
| successful save. Infobus handles notifying all interested client data models of an
| update.Is this done by passing back information in a byte[] of some kind
that is added to your EJB-tier method signature? I'm assuming
you don't do asynch comms back to your Swing client, but was curious
what approach you've adopted for this "value messenger" pattern
implementation.
interface PersonEdit {
PersonData getEditData(boolean withAddress) throws
RemoteException;
PersonData saveChanges(PersonData p, boolean updateAddress)
throws DataValidationException,
RemoteException;
}
A complete refresh of the data. The graph is keep to a manageable size for any given transaction. The data model then handles sending data change events to the appropriate "adapters". The adapter in turn extract their portion of the new data via reflection then update their respective UI components.
Do you carry back a message with just the state changes of
interest to the client, or a complete refresh of the data
that the client is seeing?
I'm not familiar with the "value messenger" pattern. We've been working with this framework for over 3 years. So far it's worked well for us. I've recently read an article in Java Report ( TRC [Knowledge Center�Articles] ) on a framework called XMLTalk. This is similar in concept to what we've done. Except we use BML from IBM alphaworks which allows us to extend the framework without having to change the XML DTD.
We've had to solve some similar requirements and was curious
if we independently picked similar "value messenger" implementation
strategies.
| We built a fairly extensive framework for creating client applications that handle<soapbox>
| complex data. We have talked about releasing it as open source, but we're a little
| behind in getting main product releases out.Sounds cool. I know from direct experience that it's not trivial
to build a Swing client that behaves like the user expects and
connects seamlessly to complex enterprise data in the EJB tier...
We've encounted two kinds of problems. One is developing the business logic so it handles a wide range of companies in our target market. The other is finding a stable, reliable, reasonably priced (for an ISV) EJB server that really and truely meets the specs. It turns out that a server can pass J2EE certification tests without actually adhearing to the spirit. It appears you can write a server that requires a ejb-ref element, but doesn't actually use it :( We're now moving to our third server vendor.
For us, the client UI is the easy part.
</soapbox>
_____________________________________________________________________
Steve Muench - Developer, Product Manager, XML Evangelist, Author
"Building Oracle XML Applications" - www.oreilly.com/catalog/orxmlapp
-- Victor
-------------------------------------------------
"I've figured out the difference between scientific
knowledge and business knowledge. Scientific knowledge
depends on facts, logic, and the rigorous testing of ideas
in the laboratory and the field. Business knowledge
depends on the assertion of pet biases with great
confidence and exorbitant billing rates." --Bob Lewis
