Home » Modeling » EMF » Wrapper for EObject and EMF Notification
| Wrapper for EObject and EMF Notification [message #499310] |
Fri, 20 November 2009 18:23  |
 Nathalie 
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi everyone,
I am looking for a solution to wrap EObject and still receives EMF Notification.
I have a view that is used to display models objects that can come from different EMF models, let's say A and B. There can be 2 instances of the view, the first one shows an instance of A and the second an instance of B.
But as the view is generated, the base classes are written to be able to handle instances of both A and B.
I have a Wrapper that wraps an EObjet from A or B. So the viewer contains Wrapper and not EObject.
The main problem is that I am not able to get the view refreshed using EMF.Edit, because the EMF notification is triggered on the EObject and the viewer contains Wrapper.
I read the EMF book 2nd Edition on 16.2 Adapters, but I am a little bit confused about the Adapters mechanism. In fact, As I am dealing with multiple models, it will be more convenient if I don't have to modify the generated code of all the models to implement the Wrapper as an adapter.
I've also heard about ReflectiveItemProvider but not sure how to use it.
Any suggestion is welcomed.Thanks.
[Updated on: Fri, 20 November 2009 18:24] Report message to a moderator |
|
|
| Re: Wrapper for EObject and EMF Notification [message #499314 is a reply to message #499310] |
Fri, 20 November 2009 18:31  |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Nathalie,
Comments below.
Nathalie wrote:
> Hi everyone,
>
> I am looking for a solution to wrap EObject efficiently.
> I have a view that is used to display models objects that can come
> from different EMF models, let's say A and B. There can be 2 instances
> of the view, the first one shows an instance of A and the second an
> instance of B.
>
> But as the view is generated, the base classes are written to be able
> to handle instances of both A and B.
> I have a Wrapper that wraps an EObjet from A or B. So the viewer
> contains Wrapper and not EObject.
>
> The main problem is that I am not able to get the view refreshed using
> EMF.Edit, because the EMF notification is triggered on the EObject and
> the viewer contains Wrapper.
EMF provides wrappers like this as well, DelegatingWrapperItemProvider,
but the wrapper listens to the item provider of the object being wrapped.
>
> I read the EMF book 2nd Edition on 16.2 Adapters, but I am a little
> bit confused about the Adapters mechanism. In fact, As I am dealing
> with multiple models, it will be more convenient if I don't have to
> modify the generated code of all the models to implement the Wrapper
> as an adapter.
> I've also heard about ReflectiveItemProvider but not sure how to use it.
> Any suggestion is welcomed.Thanks.
Your question is very open ended. I don't really understand why you
need wrappers. Normal item providers should be sufficient. To create a
specialized view different from the default, often one would create a
derived XyzItemProviderAdapterFactory with createAbc methods that create
a derived AbcItemProvider in which you make changes to the label,
children, or something like that. You'd not be modifying generated code
when doing that.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Wrapper for EObject and EMF Notification [message #499321 is a reply to message #499314] |
Fri, 20 November 2009 19:11 |
Nathalie
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Thanks for answering Ed.
In fact the Wrapper is useful for two reasons. I have an explorer that shows the contents of the two instances of my custom view.
Let's call those instances V1 and V2. I forget to mention that V1 and V2 can shows both the same model instance.
In case V1 and V2 both show A for example I will have an error cause the explorer treeviewer cannot show the same object twice.
The other reason why I need wrapper is that I need to associate the EObject with the view instance that is showing it.
I saw the DelegatingWrapperItemProvider API but I dont exactly know to use it. Is it extensible ? Can I add some custom properties there ?
Concerning this:
> Your question is very open ended. I don't really understand why you
> need wrappers. Normal item providers should be sufficient. To create a
> specialized view different from the default, often one would create a
> derived XyzItemProviderAdapterFactory with createAbc methods that
> create
> a derived AbcItemProvider in which you make changes to the label,
> children, or something like that. You'd not be modifying generated code
> when doing that.
I am using a content provider and a label provider which both extends AdapterFactory*Provider API. I am only using the generated ItemProvider of A and B and add them to the factories list of the ComposedAdapterFactory used to instantiate the content and label providers.
[Updated on: Fri, 20 November 2009 19:11] Report message to a moderator |
|
| |
| Re: Wrapper for EObject and EMF Notification [message #499947 is a reply to message #499310] |
Tue, 24 November 2009 15:07 |
Oliver Wong
Messages: 47
Registered: July 2009 |
Member |
|
|
Hi Ed, I'm working with Nathalie so perhaps I can add a few clarifying details.
We've created our own ecore model, "vmf.ecore", to describe these views (yes, we have multiple such views), and then wrote a generator which reads our ".vmf" to generate Java code which implements our views. Our "views" can actually be decomposed to two parts: the actual GUI view (e.g. a SWT TableTreeViewer), and the content and label providers (which I'll collectively refer to as "providers"). The GUI view uses the providers, but the providers are also used to integrate into a CNF-based viewer.
I'm a bit fuzzy on the details of how CNF works, but it seems like you simply register an extension which specifies an activation type, and a content and label provider. For example, you'd say "When you have an IProject, invoke this particular content provider".
The resultant output that we want to display to the user looks something like this:
IProject Test
|- Author Info VMF Plugin
| |- Author: Oliver Wong
| | |- e-mail: owong@...
| | `- tel: 555-5555
| `- Author: Nathalie
| |- e-mail: nath@...
| `- tel: 555-5556
`- CVS Commit VMF Plugin
|- Committer: Oliver Wong
| `- 289 commits
`- Committer: Nathalie
`- 382 commits
Now the "Author: Oliver Wong" and "Committer: Oliver Wong" are backed by the same underlying EObject, e.g. an instance of User.
The problem, as I understand it, is if in CNF, we simply say "Whenever you have an instance of User, invoke the Author Info VMF Content Provider" is that you'd end up with the contact information (e-mail, telephone, etc.) appearing everywhere the User EObject appears; problematically, it would also appear under the "CVS Commit VMF Plugin" section.
So what we did instead was to create a wrapper (VMFNode) which holds an additional property stating which VMF-plugin it "belongs" to. So rather than the "Author: Oliver Wong" being backed simply by the User EObject, it is backed by a VMFNode, which contains a pointer to the User EObject, and the string containing the ID of the VMF plugin it came from, e.g. "com.mycompany.vmf.authorinfo". In this way, we can display different children for the node, depending on whether it "came from" one VMF plugin versus the other.
The two problems that arises when we try to integrate with EMF are:
1) It's not clear how to integrate our wrapper with EMF's wrapper.
2) It looks like if we use ItemProviders, rather than directly returning the children (the way you'd implement a ContentProvider), you return the features from which children should be derived, which puts some limitations on us (one of which is we can't return VMFNode, but there are a few others that are important to us as well).
|
|
|
| Re: Wrapper for EObject and EMF Notification [message #499969 is a reply to message #499947] |
Tue, 24 November 2009 15:48 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Oliver,
Comments below.
Oliver Wong wrote:
> Hi Ed, I'm working with Nathalie so perhaps I can add a few clarifying
> details.
>
> We've created our own ecore model, "vmf.ecore", to describe these
> views (yes, we have multiple such views), and then wrote a generator
> which reads our ".vmf" to generate Java code which implements our
> views. Our "views" can actually be decomposed to two parts: the actual
> GUI view (e.g. a SWT TableTreeViewer), and the content and label
> providers (which I'll collectively refer to as "providers"). The GUI
> view uses the providers, but the providers are also used to integrate
> into a CNF-based viewer.
>
> I'm a bit fuzzy on the details of how CNF works, but it seems like you
> simply register an extension which specifies an activation type, and a
> content and label provider. For example, you'd say "When you have an
> IProject, invoke this particular content provider".
>
> The resultant output that we want to display to the user looks
> something like this:
>
> IProject Test
> |- Author Info VMF Plugin
> | |- Author: Oliver Wong
> | | |- e-mail: mailto:owong@...
> | | `- tel: 555-5555
> | `- Author: Nathalie
> | |- e-mail: mailto:nath@...
> | `- tel: 555-5556
> `- CVS Commit VMF Plugin
> |- Committer: Oliver Wong | `- 289 commits
> `- Committer: Nathalie
> `- 382 commits
>
> Now the "Author: Oliver Wong" and "Committer: Oliver Wong" are backed
> by the same underlying EObject, e.g. an instance of User.
I see.
>
> The problem, as I understand it, is if in CNF, we simply say "Whenever
> you have an instance of User, invoke the Author Info VMF Content
> Provider" is that you'd end up with the contact information (e-mail,
> telephone, etc.) appearing everywhere the User EObject appears;
> problematically, it would also appear under the "CVS Commit VMF
> Plugin" section.
Yes, that's right.
>
> So what we did instead was to create a wrapper (VMFNode) which holds
> an additional property stating which VMF-plugin it "belongs" to. So
> rather than the "Author: Oliver Wong" being backed simply by the User
> EObject, it is backed by a VMFNode, which contains a pointer to the
> User EObject, and the string containing the ID of the VMF plugin it
> came from, e.g. "com.mycompany.vmf.authorinfo". In this way, we can
> display different children for the node, depending on whether it "came
> from" one VMF plugin versus the other.
That makes sense.
>
> The two problems that arises when we try to integrate with EMF are:
>
> 1) It's not clear how to integrate our wrapper with EMF's wrapper.
You don't necessarily have to but it's good to look at how something
similar is designed.
> 2) It looks like if we use ItemProviders, rather than directly
> returning the children (the way you'd implement a ContentProvider),
> you return the features from which children should be derived, which
> puts some limitations on us (one of which is we can't return VMFNode,
> but there are a few others that are important to us as well).
Yes, but that's just the default implementation. You can specialize it
to return your wrapper objects. Also have a close look at the
getChilden method; it does wrapping as needed there too. The wrappers
probably should implement all the I*Item*Provider interfaces that will
be needed and likely should add themselves as adapters so they can
produce viewer updates.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Wrapper for EObject and EMF Notification [message #499990 is a reply to message #499969] |
Tue, 24 November 2009 16:25 |
Nathalie
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
I just want to clarify something. I did a research yesterday as I was a little bit confused on the ItemProvider and AdapterFactory*Providers usage.
I find out that there seems to be two strategies.
The first one that you are talking about is to not overwrite AdapterFactory*Providers, but instead extends the ItemProviders, and this make more sense with using the DelegatingWrapperItemProvider, and specify there what the getChildren, getText, ... should do. The AdapterFactory*Providers classes will be only extended for the purpose of CNF, but none of their methods will be overwritten. They will do the job they are supposed to do, delegate to ItemProvider. Correct me if I am wrong.
The other strategy that we are using right now is to extend the AdapterFactory*Providers. All the logic to get the children and the labels is put in there and we only register the generated ItemProvider in the adapter factory to get notifications.
To use EMF wrappers here we have to specialize the generated ItemProvider and make them extend the DelegatingWrapperItemProvider class. So as in the first case the specialization is what going to give us the wrapping we want.
For me in both case it is possible to achieve the same results, but I don't know if there is one strategy that is more suitable.
|
|
|
| Re: Wrapper for EObject and EMF Notification [message #500003 is a reply to message #499990] |
Tue, 24 November 2009 16:45 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Nathalie,
Comment sbelow.
Nathalie wrote:
> Hi Ed,
> I just want to clarify something. I did a research yesterday as I was
> a little bit confused on the ItemProvider and AdapterFactory*Providers
> usage.
> I find out that there seems to be two strategies.
> The first one that you are talking about is to not overwrite
> AdapterFactory*Providers, but instead extends the ItemProviders, and
> this make more sense with using the DelegatingWrapperItemProvider, and
> specify there what the getChildren, getText, ... should do. The
> AdapterFactory*Providers classes will be only extended for the purpose
> of CNF, but none of their methods will be overwritten. They will do
> the job they are supposed to do, delegate to ItemProvider. Correct me
> if I am wrong.
That sounds accurate.
> The other strategy that we are using right now is to extend the
> AdapterFactory*Providers. All the logic to get the children and the
> labels is put in there and we only register the generated ItemProvider
> in the adapter factory to get notifications.
This is sounding less promising to me. The specialized logic for
producing the label implies specialized logic for handling notifications
when the information used for the label changes. So you need to hook up
specialized adapters as well. As such, you would seem to be better off
using exactly the pattern that EMF is already using...
> To use EMF wrappers here we have to specialize the generated
> ItemProvider and make them extend the DelegatingWrapperItemProvider class.
I'm only suggesting you look at that as an example. It sounds likely
that you'll want to extend a generated AbcItemProvider and make that act
as a wrapper; it should be well suited for that purpose given it has
logic for computing a label you can specialize and given it's an adapter
that can respond to notifications. You just need to be sure when you
create one it's hooked into the same factory as the basic item providers
you're already creating.
> So as in the first case the specialization is what going to give us
> the wrapping we want.
>
> For me in both case it is possible to achieve the same results, but I
> don't know if there is one strategy that is more suitable.
You're dealing with quite a complex situation and of course the item
provider design isn't exactly trivially simple either, but if you depart
from it and start using alternative approaches, you'll end up somewhere
that's difficult for me to help you with. I don't think I can properly
help with just little snips of knowledge. I don't know for example how
you are managing the creation of your wrappers or how you're ensuring
that the same wrapper instance is returned each time the parent is asked
for the children...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 13:10:36 GMT 2024
Powered by FUDForum. Page generated in 0.03891 seconds |
] 
Search
Help
Register
Login
Home
