| recursive notification to parent question [message #499360] |
Sat, 21 November 2009 06:32  |
Eclipse User |
|
|
|
I have a fairly simple EMF class, Rebutter, whose java annotations consist of the following:
/**
* @model
*/
public interface Rebutter {
/**
* @model containment="true" max=1 opposite="rebutted"
*/
Rebutter getRebutter();
/**
* @model changeable="false" transient="true" derived="true" volatile="true"
*/
boolean isAccepted();
/**
* @model changeable="false" opposite="rebutter"
*/
Rebutter getRebutted();
}
If I generate all (using the latest releases of eclipse and EMF) and implement the derived isAccepted() attribute in RebutterImpl with the following:
public boolean isAccepted() {
return rebutter!=null ? !rebutter.isAccepted() : true;
}
Then I allow a chain of rebutter objects whose accepted flag depends on it's child chain.
I have a problem in the editor, though. I can't get updates to visibly bubble up the chain. Here's what I do:
I change the generated RebutterItemProvider to
1. show the accepted status of the rebutter by appending an "X"
2. update notifyChanged to signal a labelUpdate if the Rebutter changes
So, in the editor, if I add a rebutter to an existing rebutter, then it's label changes, but not it's parent (rebutted) rebutter.
I think the best crack I had at this was to change the generated RebutterImpl setRebutter method to pass a notification up the chain...
public void setRebutter(Rebutter newRebutter) {
if (newRebutter != rebutter) {
boolean oldAccepted = this.isAccepted();
...
// notify rebutted that this object's accepted flag may have changed
this.getRebutted().eNotify(new ENotificationImpl(this, Notification.SET, DecisionPackage.REBUTTER__ACCEPTED, oldAccepted, this.isAccepted()));
}
...
}
but this didnt work and maybe doesnt quite smell right. Any pointers in the right direction would be most appreciated.
Matt
|
|
|
| Re: recursive notification to parent question [message #499361 is a reply to message #499360] |
Sat, 21 November 2009 07:22  |
| Eclipse User |
|
|
|
Matt,
Comments below.
Matt South wrote:
> I have a fairly simple EMF class, Rebutter, whose java annotations
> consist of the following:
> /**
> * @model
> */
> public interface Rebutter {
> /**
> * @model containment="true" max=1 opposite="rebutted"
> */
> Rebutter getRebutter();
>
> /**
> * @model changeable="false" transient="true" derived="true"
> volatile="true"
> */
> boolean isAccepted();
>
> /**
> * @model changeable="false" opposite="rebutter"
> */
> Rebutter getRebutted();
> }
> If I generate all (using the latest releases of eclipse and EMF) and
> implement the derived isAccepted() attribute in RebutterImpl with the
> following:
> public boolean isAccepted() {
> return rebutter!=null ? !rebutter.isAccepted() : true;
It's the same as return rebutter == null || !rebutter.isAccepted()
> }
> Then I allow a chain of rebutter objects whose accepted flag depends
> on it's child chain.
> I have a problem in the editor, though. I can't get updates to
> visibly bubble up the chain. Here's what I do:
> I change the generated RebutterItemProvider to 1. show the accepted
> status of the rebutter by appending an "X"
> 2. update notifyChanged to signal a labelUpdate if the Rebutter changes
> So, in the editor, if I add a rebutter to an existing rebutter, then
> it's label changes, but not it's parent (rebutted) rebutter.
>
> I think the best crack I had at this was to change the generated
> RebutterImpl setRebutter method to pass a notification up the chain...
You might solve it at the item provider level as well by synthesizing
firing viewer notifications up the container chain.
>
> public void setRebutter(Rebutter newRebutter) {
> if (newRebutter != rebutter) {
> boolean oldAccepted = this.isAccepted();
> ..
> // notify rebutted that this object's accepted flag may have
> changed
> this.getRebutted().eNotify(new ENotificationImpl(this,
> Notification.SET, DecisionPackage.REBUTTER__ACCEPTED, oldAccepted,
> this.isAccepted()));
You've already established there is a rebutter so calling the getter
here seems not necessary. And isn't it the newRebutter's accepted state
that you should be taking into account? Do you want "touch"
notifications if the accepted state doesn't really change?
> }
> ..
> }
> but this didnt work and maybe doesnt quite smell right.
You might want to use the setRebutterGen "pattern" to avoid changing the
base method... Maybe it didn't work because it's always a touch
notification and I don't see a recursive traversal walking up the
container chain. Isn't that needed?
> Any pointers in the right direction would be most appreciated.
>
> Matt
>
|
|
|
|
|
| Re: recursive notification to parent question [message #499455 is a reply to message #499426] |
Sun, 22 November 2009 13:15 |
| Eclipse User |
|
|
|
Hi Ed,
I've added a method to the RebutterImpl class:
private void notifyAcceptedUpdate(boolean oldValue, boolean newValue) {
if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.SET, DecisionPackage.REBUTTER__ACCEPTED, oldValue, newValue));
if (getRebutted()!=null) ((RebutterImpl) getRebutted()).notifyAcceptedUpdate(!oldValue, !newValue);
}
And altered my update of the generated setRebutter to use this new method:
public void setRebutter(Rebutter newRebutter) {
if (newRebutter != rebutter) {
boolean oldAccepted = this.isAccepted();
...
// check for change of accepted flag
if (oldAccepted != isAccepted()) notifyAcceptedUpdate(oldAccepted, isAccepted());
}
...
}
Now the updates do get bubbled up in the editor and I'm unstuck. Thanks for your continued help!
Matt
|
|
|
Powered by
FUDForum. Page generated in 0.05264 seconds
Home