You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Steffen Glomb <gl...@googlemail.com> on 2007/06/10 01:06:51 UTC
Databinding, dataobject <-> UI Component
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
Re: Databinding, dataobject <-> UI Component
Posted by kelvin goodson <ke...@gmail.com>.
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 <fr...@ca.ibm.com> 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.
>
> bert.robben@agfa.com 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 <fr...@ca.ibm.com>
> > 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.
> >
> > bert.robben@agfa.com 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" <gl...@googlemail.com>
> > > 11/06/2007 19:14
> > > Please respond to
> > > tuscany-user@ws.apache.org
> > >
> > >
> > > To
> > > tuscany-user@ws.apache.org, kelvin@thegoodsons.org.uk
> > > 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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Databinding, dataobject <-> UI Component
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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.
bert.robben@agfa.com 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 <fr...@ca.ibm.com>
> 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.
>
> bert.robben@agfa.com 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" <gl...@googlemail.com>
> > 11/06/2007 19:14
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > tuscany-user@ws.apache.org, kelvin@thegoodsons.org.uk
> > 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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Databinding, dataobject <-> UI Component
Posted by be...@agfa.com.
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 <fr...@ca.ibm.com>
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.
bert.robben@agfa.com 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" <gl...@googlemail.com>
> 11/06/2007 19:14
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> tuscany-user@ws.apache.org, kelvin@thegoodsons.org.uk
> 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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Databinding, dataobject <-> UI Component
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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.
bert.robben@agfa.com 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" <gl...@googlemail.com>
> 11/06/2007 19:14
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> tuscany-user@ws.apache.org, kelvin@thegoodsons.org.uk
> 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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Databinding, dataobject <-> UI Component
Posted by be...@agfa.com.
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" <gl...@googlemail.com>
11/06/2007 19:14
Please respond to
tuscany-user@ws.apache.org
To
tuscany-user@ws.apache.org, kelvin@thegoodsons.org.uk
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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Databinding, dataobject <-> UI Component
Posted by Steffen Glomb <gl...@googlemail.com>.
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 <ke...@gmail.com> 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 <gl...@googlemail.com> 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
> >
>
Re: Databinding, dataobject <-> UI Component
Posted by kelvin goodson <ke...@gmail.com>.
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 <gl...@googlemail.com> 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
>