| > Do you bind your Swing forms to Collections of Value Objects
| > or to remote Entity Beans ?
|
| We use stateful session beans for most use cases where editing of data occurs.
| Those stateful session beans interact with entity beans. We use value objects to
| hold the actual data.
ok. got it.
| > If you're showing information on a Swing form like this:
| >
| > Name: [Steve ]
| > Level: [Silver ][v] (supposed to look like a poplist) :-)
| > CreditLimit: [1000 ]
| > :
| > lots more info here
| > :
| >
| > and suppose the user pulls the poplist and sets the
| > customer level to [Platinum] and does "File / Save"...
| >
| > Assuming you're EJB-tier business logic has code that
| > says,
| >
| > :
| > if (getLevel().equals("Platinum")) {
| > setCreditLimit(9000);
| > }
| >
|
| 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.
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?
We've had to solve some similar requirements and was curious
if we independently picked similar "value messenger" implementation
strategies.
| > Just curious how you handle this issue in your app.
|
| We're adding JMS notification to notify other clients of a change as well.
Interesting...
| We built a fairly extensive framework for creating client applications that handle
| 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...
_____________________________________________________________________
Steve Muench - Developer, Product Manager, XML Evangelist, Author
"Building Oracle XML Applications" - www.oreilly.com/catalog/orxmlapp
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
