I'll try to explain what we do. Our requirements - use data objects in a server side environment where there is no UI - use data objects tightly integrated in a swing-based UI
Due to all kind of reasons beyond our control, client-side implementation classes have a different release cycle than our server side classes. As such it is very difficult to reuse the same classes both on client and server. Strangely, but true, this is especially the case for the classes inside our UI framework. We solved this issue by creating a "core" sdo module. This module provides an implementation of the SDO spec. On the server side we only use this core module. To allow for independent specialization for UI events, we implemented the DataObject interface in our core in such a way that most of the functionality is in a class called "AbstractDataObject". An extension to this class basically has to provide an implementation for set(Property, Object) and get(Property). The core provides a simple implementation based on an array of objects (an alternative could be a Map). The UI extension provides an implementation based on our UI framework with a different implementation for the property setters and getters (typically such that UI events are delivered). The UI extension also defined an extenstion to DataObject (called ObservableDataObject) to allow (de)registration of event listeners on properties. The rest of the UI extension just provides a type-safe ObservableDataFactory. One issue we encountered was the representation of many-valued properties. Our UI doesn't want to represent lists of objects as instances of java.util.List but instead as some form of javax.swing.ListModel which (for legacy reasons) didn't and couldn't implement java.util.List. This was especially annoying because the core implementation (for instance for XMLhelper and serialization) of course needs to iterate over all values of a multi-valued property. We solved this by adding a getIterator(Property) method on our "AbstractDataObject". A second implementation issue we encountered was related to the inheritance hierarchy. Our ObservableDataObject on the one hand needed functionality of DataObject and on the other hand for the UI it needed functionality of ICompositeObject (a concept defined in our UIFramework). Both interfaces have existing abstract implementations. As multiple inheritance is not allowed in Java, we couldn't have an implementation class inheriting the behaviour from both abstract implementations (although conceptually this should be possible because the two interfaces have nothing in common). So we ended up with either having to use a delegation pattern or to copy the source-code of on of our abstract implementations. I hope this makes it a bit more clear. Feel free to ask for more details. Bert Frank Budinsky <[EMAIL PROTECTED]> 12/06/2007 14:42 Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: Databinding, dataobject <-> UI Component Hi Bert (and Steffen), As far as adding notification support in Tuscany is concerned, it would not be very difficult, given the underlying EMF implementation. Tuscany uses the EMF notification framework to implement ChangeSummary, so it wouldn't be hard to provide a way to allow (UI) observers to also be attached. What we don't want is for users to use the underlying EMF EAdapter API directly, because EMF is considered an internal implementation detail which is subject to change. Unfortunately, since SDO does not provide a standard API for doing this, we will need to come up with something Tuscany-specific, but longer term we could try to push a design back into the SDO spec (version 3). So, I'd be very interested in any ideas you have, and to see how you've done it. Please do explain more details. Thanks, Frank. [EMAIL PROTECTED] wrote on 06/12/2007 03:23:21 AM: > This is actually one of the main reasons why we don't use the Tuscany SDO > implementation. We made our own proprietary implementation of the SDO spec > in order to be able to bind our DataObjects into our UI framework. > > As a matter of fact, our implementation implements databinding as an > extension. In its core, it just implements the SDO spec. But it allows > without too much work to extend the implementation in a separate > component. This separate component implements databinding. It's fairly > small because it only needs to deal with this databinding. > If people are interested, I can explain this in more detail. > > Maybe Tuscany could allow something like this as well? > > Bert > > > > > "Steffen Glomb" <[EMAIL PROTECTED]> > 11/06/2007 19:14 > Please respond to > tuscany-user@ws.apache.org > > > To > tuscany-user@ws.apache.org, [EMAIL PROTECTED] > cc > > Subject > Re: Databinding, dataobject <-> UI Component > > > > > > > > Hi Kelvin, > > thank you for your response. I conclude: > -> no automatic databinding from the dataobjects to UI Components in the > Swing world with SDO Spec. > > I have hard time to understand why this is (intentionally?) omitted. > > Its a small step to some form of JavaBean PropertyChangeSupport. > > Maybe anyone has a link to where this might have been discussed? > > Thanks > Steffen > > > > On 6/11/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > Steffen, > > > > there's no provision in the SDO API for receiving direct notification > of > > changes to values. It would be an unportable and fragile thing to do to > > rely > > on the EMF underpinnings of the Tuscany SDO implementation. I don't > think > > > > there is anything to offer here from the pure SDO API level. > > > > Regards, Kelvin. > > > > On 10/06/07, Steffen Glomb <[EMAIL PROTECTED]> wrote: > > > > > > hopefully common Scenario: > > > Using SDO in a Swing Rich Client application, > > > pulling the datagraph to the client. Fields from in the User Interface > > are > > > bound to properties of the dataobjects in the graph. > > > Client side business logic causes changes in the dataobjects. > > > One might want to have these changes automatically synchronized to the > > UI > > > Components. > > > > > > > > > Problem: > > > I am having difficulties finding a simple way to implement the data > > > binding. > > > > > > > > > Question: > > > How can i get the change notification from the dataobject? > > > ( dataobject.eAdapters() returns an umodifieable list) > > > > > > Solution? > > > The only way i found to accomplish this is through adding an adapter > to > > > the changesummary and unscrambling the changeentries as they are > added. > > > > > > Is this the intended way? why is the changenotification of EObjectImpl > > cut > > > off ? > > > > > > > > > Thanks for sharing your expertise > > > Steffen > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
