|
|
|
|
|
|
|
|
|
Re: EMF with BeanSupport? [message #902720 is a reply to message #902716] |
Mon, 20 August 2012 06:49 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Ludwig,
Comments below.
On 20/08/2012 7:39 AM, Ludwig Moser wrote:
> let me explain it by a small example
>
> we have ECLasses Person & Address
> where Person has Attributes name, adress (an EReference to EClass
> Address), etc
> where Address has Attributes street, city, country
>
> get an notification from an instance of Eclass Person
> and i need to access the attribute street of this person...
For the purpose of producing a bean notification. I would have imagined
that only the Address bean produces notifications for changes to the
street, which is a property of Address not a property of Person.
> i usualy do this with an FeaturePath
> FeaturePath.fromList(eStructuralFeatureGetAddress,
> eStructuralFeatureGetStreet)
> by using this featurePath i could create the String (which java beans
> uses to resolve the getter&setter)
> btw: the string would be: address.street (which gets resolved to
> getAddress().getStreet())
>
> how can i do this with only one structuralfeature from the notification?
Person will only get notifications for changes to its own features.
>
> i hope you understand now what i need, or what my problem is.
No, I just have more questions. Isn't it the case that beans produce
notifications only for changes to their own properties? After all, the
Address bean doesn't know which Person bean refers to it; it might even
be shared among many persons (and you've not mentioned whether it's a
containment reference, which would imply it's only referenced by one
Person).
> thanks for your patience :)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Re: EMF with BeanSupport? [message #902833 is a reply to message #902757] |
Mon, 20 August 2012 16:56 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Ludwig,
Comments below.
On 20/08/2012 11:44 AM, Ludwig Moser wrote:
> you are right notifications for any change in an attribute is only
> needed the object which contains it.
>
> its true that there might be an situation which makes differences if
> its a containment or not.
That will affect whether objects are shared. A containment reference
guarantees that the object is contained in at most one place no matter
how much you might try to share it; EMF will automatically remove it
from another container.
>
> in my case its 'only' for glazedlists, which do not support EMF.
>
> i do bind some objects to my table then the
> lists register for property-changes on the properties i display in my
> table.
> if any of the bound data changes, i fire the correlating property
> change event;
> (if the event is not registered by the list it gets dropped, otherwise
> the table updates the cell which got changed)
>
> btw: this is my current adapter
>
> Adapter adapter = new AdapterImpl() {
> public void notifyChanged(Notification n) {
> EStructuralFeature feature = (EStructuralFeature)
> n.getFeature();
> if (feature == null) {
> return;
> }
> PropertyChangeEvent evt = new
> PropertyChangeEvent(n.getNotifier(),
> feature.getName(), n.getOldValue(),
> n.getNewValue()); }
> };
>
> do you think the way i do it is incorrect?
I don't know enough about PropertyChangeEvent to say if this is
correct. OldValue and NewValue mean different things depending on the
type of Notification event...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04631 seconds