Eclipse Community Forums: EMF » Nested Notification Question

Help

Home

Home » Modeling » EMF » Nested Notification Question

Show: Today's Messages :: Show Polls :: Message Navigator

Nested Notification Question [message #428744]

Sun, 29 March 2009 02:57

Steven Punte

Messages: 34
Registered: July 2009

Member

Assume one has a nested EMF structure:

class Aaaa
listBbbb of class Bbbb
listCccc of class Cccc

I have selected Notify=true on the genmodel property of all member data.

I have an adapter attached to the top-level object of Aaaa.

When I add a new object into listBbbb, the top-level adapter notifier is
called.

However, when I add a new object into listCccc, the top-level adapter is
NOT called.

Is there a way to make notification in such nested structure propagate
upwards? This would greatly simplify the design of a tree viewer
presenting a large tree structure as oppose to attaching adapters
everywhere.

Thanks in advance:
Steve Punte

Report message to a moderator

Re: Nested Notification Question [message #428745 is a reply to message #428744]

Sun, 29 March 2009 03:33

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Steve,

Comments below.

Steven Punte wrote:
> Assume one has a nested EMF structure:
>
> class Aaaa
> listBbbb of class Bbbb
> listCccc of class Cccc
>
>
> I have selected Notify=true on the genmodel property of all member data.
>
> I have an adapter attached to the top-level object of Aaaa.
>
> When I add a new object into listBbbb, the top-level adapter notifier
> is called.
>
> However, when I add a new object into listCccc, the top-level adapter
> is NOT called.
An object only gets notifications for changes to its own features...
>
> Is there a way to make notification in such nested structure propagate
> upwards?
No.
> This would greatly simplify the design of a tree viewer presenting a
> large tree structure as oppose to attaching adapters everywhere.
How so? Tree views work very nicely with notifications going directly
only to the parent node. There's no need for the grandparent to know
about such changes, since they don't directly affect it.

Perhaps you'd be interested in an EContentAdapter, but I don't see how
they'd be particularly useful for a tree viewer...
>
> Thanks in advance:
> Steve Punte
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Nested Notification Question [message #428788 is a reply to message #428745]

Mon, 30 March 2009 16:27

Steven Punte

Messages: 34
Registered: July 2009

Member

Ed Merks wrote:

> Steve,

>>
>> However, when I add a new object into listCccc, the top-level adapter
>> is NOT called.
>
> An object only gets notifications for changes to its own features...

Yes, I'm starting to realize this.

>> This would greatly simplify the design of a tree viewer presenting a
>> large tree structure as oppose to attaching adapters everywhere.
>
> How so? Tree views work very nicely with notifications going directly
> only to the parent node. There's no need for the grandparent to know
> about such changes, since they don't directly affect it.

In this case, how does the parent node notify the appropriate leaf in the
tree viewer? I only have the one adapter at the very top of my emf tree
structure which calls refresh of the treeviewer.

Do I need to create and apply an adapter/observer at EVERY parent node of
my emf tree, or is there a simpler more elegant way?

Thanks for you help.

Steve Punte

Report message to a moderator

Re: Nested Notification Question [message #428791 is a reply to message #428788]

Mon, 30 March 2009 17:32

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Steve,

Comments below.

Steven Punte wrote:
> Ed Merks wrote:
>
>> Steve,
>
>>>
>>> However, when I add a new object into listCccc, the top-level
>>> adapter is NOT called.
>>
>> An object only gets notifications for changes to its own features...
>
> Yes, I'm starting to realize this.
>
>
>>> This would greatly simplify the design of a tree viewer presenting a
>>> large tree structure as oppose to attaching adapters everywhere.
>>
>> How so? Tree views work very nicely with notifications going
>> directly only to the parent node. There's no need for the
>> grandparent to know about such changes, since they don't directly
>> affect it.
>
> In this case, how does the parent node notify the appropriate leaf in
> the tree viewer?
It doesn't. I'm not sure why you believe that's necessary.
> I only have the one adapter at the very top of my emf tree structure
> which calls refresh of the treeviewer.
You're not using the generated item providers?
>
> Do I need to create and apply an adapter/observer at EVERY parent node
> of my emf tree, or is there a simpler more elegant way?
Item providers are very simple and elegant. I have a feeling you've
overlooked them.
>
> Thanks for you help.
>
> Steve Punte
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Nested Notification Question [message #428802 is a reply to message #428791]

Mon, 30 March 2009 23:08

Steven Punte

Messages: 34
Registered: July 2009

Member

Ed Merks wrote:

>> I only have the one adapter at the very top of my emf tree structure
>> which calls refresh of the treeviewer.
> You're not using the generated item providers?

No, I am not. They are excellent at portraying the exact tree from a
software developer perspective, but from an end-user perspective they are
not sufficiently user friendly.

>> Do I need to create and apply an adapter/observer at EVERY parent node
>> of my emf tree, or is there a simpler more elegant way?
> Item providers are very simple and elegant. I have a feeling you've
> overlooked them.

I am certainly in the dark with respect to the machinery that manages
these providers. Does EMF.edit machinery instantiate an ItemProvider for
each node in the users EMF tree? And does it create and destroy such
ItemProviders as the user add and deletes nodes?

Thanks for you help.
Steve Punte

Report message to a moderator

Re: Nested Notification Question [message #428804 is a reply to message #428802]

Tue, 31 March 2009 00:21

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Steve,

Comments below.

Steven Punte wrote:
> Ed Merks wrote:
>
>>> I only have the one adapter at the very top of my emf tree structure
>>> which calls refresh of the treeviewer.
>> You're not using the generated item providers?
>
> No, I am not. They are excellent at portraying the exact tree from a
> software developer perspective, but from an end-user perspective they
> are not sufficiently user friendly.
They determine which features shown as children and how the label of
each item is surfaced. They're infinitely malleable. I can't imagine
how you'd induce an end-user tree without the same concepts applying.
Indeed that seems the very problem with which you are faced...
>
>>> Do I need to create and apply an adapter/observer at EVERY parent
>>> node of my emf tree, or is there a simpler more elegant way?
>> Item providers are very simple and elegant. I have a feeling you've
>> overlooked them.
>
> I am certainly in the dark with respect to the machinery that manages
> these providers.
So in that darkness you seek to find an alternative solution to the very
same problem.... Likely a simple one that has yet to occur to anyone
else...
> Does EMF.edit machinery instantiate an ItemProvider for each node in
> the users EMF tree?
You'll note there is the concept of singletons. I.e., stateless item
providers, the default, which, given an instance object, can answer all
the questions about how that object should be viewed as a tree node.
> And does it create and destroy such ItemProviders as the user add and
> deletes nodes?
Why ask when a fully functional editor is generated for your detailed
analysis? The debugger will answer every question more quickly than I.
>
> Thanks for you help.
> Steve Punte
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO] Legacy and Oracle.
Next Topic:	[CDO] Locks management behavior.

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 08:52:20 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter