For anyone who has an interest in how this thread is unfolding, there is a follow up in https://issues.apache.org/jira/browse/TUSCANY-1527, which I hope to progress some more soon.
Kelvin. On 14/06/2007, Frank Budinsky <[EMAIL PROTECTED]> wrote: > Hi Bert, > > I think I'm following this at a high level, but need to see some code to > understand the details - especially exactly what the client API for > hooking up observers looks like. Is your code confidential, or could you > send us a zip file with the code in it. If you can contribute it, I think > that we may be able to do something similar in Tuscany. We probably won't > need to have a separate ObservableDataObject class, though, because the > underlying notification mechanism is already in place (to support > ChangeSummary), so we just need to enable it and provide a way for clients > to use it. > > By the way, I did ask one of the original authors of the SDO spec the > question of why notification was initially left out of SDO, and the answer > was simply because there were too many other issues that needed to be > agreed on between the collaboration members, and in terms of priority, > notification didn't make it high enough on the list. There was, however, > interest in adding it in the future. > > Frank. > > [EMAIL PROTECTED] wrote on 06/14/2007 07:02:09 AM: > > > 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 > > [email protected] > > > > > > To > > [email protected] > > 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 > > > [email protected] > > > > > > > > > To > > > [email protected], [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] > > > > > --------------------------------------------------------------------- > 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]
