Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » EMF and GEF: an interesting but strange result...
EMF and GEF: an interesting but strange result... [message #204880] Thu, 08 December 2005 13:35 Go to next message
Eclipse UserFriend
Originally posted by: jkarlik.info.fundp.ac.be

I have noticed something really strange whith the use of GEF and EMF
together. I have one Eclipse View which creates 10000 instances of a
EObject (called tags) and put these instances in one EObject instance
that I call the document. So a document containts 10000 tags. The
content is passed to the graphicalEditPartViewer as usually. And the
view is built like described in the GEF specification.

So, Each edit part is linked directly to a EObject. (a tag or a
document). My edits parts implement Adapter to get notified by a
changement in the EMF metamodel (=the 10000 EObect instances create
before by the view). Each edit part listens his associated EObject.
(=the model object returned by getModel()).

When I click on the view, I target a modification to the metamodel and I
m surprised to see that the notification process is not really fast. On
the contrary, when I consider the view itself as a Adapter instead of
the editParts, the notification process is realley FASTER! why? I don't
understand! So it seems that if a class (my view for example) creates
EObjects, this class is more likely to be notifyed faster than the
others (edits pars) because it s that class which created the EObjects!
Surprising!

So for this, I tried something else. Instead of directly attaching my
EObjects to the edits parts, I created Java classes (A Class Document
and class Tag). These java classes are linked to the edit parts,
implement Adapter (in order to get notifyed!) and contain a reference of
a corresponding EObject. When I click on the view, it modifies a
metamodel's EObject >>>> my java classes get notifyed and tell the edit
parts to update the view according to the corresponding EObject.

And it's really fast, the view changes very quickly! But I don't want to
have this mess in my code. I want only one model (not the both like in
this case: emf EObjects + java classes!!)

How can I do to resolve my problem??? Can you bring some explanations to
this behaviour?
Re: EMF and GEF: an interesting but strange result... [message #204897 is a reply to message #204880] Thu, 08 December 2005 13:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jkarlik.info.fundp.ac.be

karlik joachim a écrit :
> I have noticed something really strange whith the use of GEF and EMF
> together. I have one Eclipse View which creates 10000 instances of a
> EObject (called tags) and put these instances in one EObject instance
> that I call the document. So a document containts 10000 tags. The
> content is passed to the graphicalEditPartViewer as usually. And the
> view is built like described in the GEF specification.
>
> So, Each edit part is linked directly to a EObject. (a tag or a
> document). My edits parts implement Adapter to get notified by a
> changement in the EMF metamodel (=the 10000 EObect instances create
> before by the view). Each edit part listens his associated EObject.
> (=the model object returned by getModel()).
>
> When I click on the view, I target a modification to the metamodel and I
> m surprised to see that the notification process is not really fast. On
> the contrary, when I consider the view itself as a Adapter instead of
> the editParts, the notification process is realley FASTER! why? I don't
> understand! So it seems that if a class (my view for example) creates
> EObjects, this class is more likely to be notifyed faster than the
> others (edits pars) because it s that class which created the EObjects!
> Surprising!
>
> So for this, I tried something else. Instead of directly attaching my
> EObjects to the edits parts, I created Java classes (A Class Document
> and class Tag). These java classes are linked to the edit parts,
> implement Adapter (in order to get notifyed!) and contain a reference of
> a corresponding EObject. When I click on the view, it modifies a
> metamodel's EObject >>>> my java classes get notifyed and tell the edit
> parts to update the view according to the corresponding EObject.
>
> And it's really fast, the view changes very quickly! But I don't want to
> have this mess in my code. I want only one model (not the both like in
> this case: emf EObjects + java classes!!)
>
> How can I do to resolve my problem??? Can you bring some explanations to
> this behaviour?

I want also to add the fact that I created the EMF class and EObjects
dynamically by coding it by hand. I don't know if it can be useful for
your understanding of the problem but we never know :-)
Re: EMF and GEF: an interesting but strange result... [message #204929 is a reply to message #204880] Thu, 08 December 2005 17:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

There is no way to tell what is happening based on the description you have
given. The best guess I could make is that you are calling a method like
refreshChildren() in response to each eobject notification. This method is
not efficient. You should call addChild or removeChild directly.

"karlik joachim" <jkarlik@info.fundp.ac.be> wrote in message
news:dn9cuj$oui$1@news.eclipse.org...
>I have noticed something really strange whith the use of GEF and EMF
>together. I have one Eclipse View which creates 10000 instances of a
>EObject (called tags) and put these instances in one EObject instance that
>I call the document. So a document containts 10000 tags. The content is
>passed to the graphicalEditPartViewer as usually. And the view is built
>like described in the GEF specification.
>
> So, Each edit part is linked directly to a EObject. (a tag or a document).
> My edits parts implement Adapter to get notified by a changement in the
> EMF metamodel (=the 10000 EObect instances create before by the view).
> Each edit part listens his associated EObject. (=the model object returned
> by getModel()).
>
> When I click on the view, I target a modification to the metamodel and I m
> surprised to see that the notification process is not really fast. On the
> contrary, when I consider the view itself as a Adapter instead of the
> editParts, the notification process is realley FASTER! why? I don't
> understand! So it seems that if a class (my view for example) creates
> EObjects, this class is more likely to be notifyed faster than the others
> (edits pars) because it s that class which created the EObjects!
> Surprising!
>
> So for this, I tried something else. Instead of directly attaching my
> EObjects to the edits parts, I created Java classes (A Class Document and
> class Tag). These java classes are linked to the edit parts, implement
> Adapter (in order to get notifyed!) and contain a reference of a
> corresponding EObject. When I click on the view, it modifies a metamodel's
> EObject >>>> my java classes get notifyed and tell the edit parts to
> update the view according to the corresponding EObject.
>
> And it's really fast, the view changes very quickly! But I don't want to
> have this mess in my code. I want only one model (not the both like in
> this case: emf EObjects + java classes!!)
>
> How can I do to resolve my problem??? Can you bring some explanations to
> this behaviour?
Re: EMF and GEF: an interesting but strange result... [message #204951 is a reply to message #204929] Fri, 09 December 2005 02:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jkarlik.info.fundp.ac.be

Randy Hudson a écrit :
> There is no way to tell what is happening based on the description you have
> given. The best guess I could make is that you are calling a method like
> refreshChildren() in response to each eobject notification. This method is
> not efficient. You should call addChild or removeChild directly.
>
> "karlik joachim" <jkarlik@info.fundp.ac.be> wrote in message
> news:dn9cuj$oui$1@news.eclipse.org...
>
>>I have noticed something really strange whith the use of GEF and EMF
>>together. I have one Eclipse View which creates 10000 instances of a
>>EObject (called tags) and put these instances in one EObject instance that
>>I call the document. So a document containts 10000 tags. The content is
>>passed to the graphicalEditPartViewer as usually. And the view is built
>>like described in the GEF specification.
>>
>>So, Each edit part is linked directly to a EObject. (a tag or a document).
>>My edits parts implement Adapter to get notified by a changement in the
>>EMF metamodel (=the 10000 EObect instances create before by the view).
>>Each edit part listens his associated EObject. (=the model object returned
>>by getModel()).
>>
>>When I click on the view, I target a modification to the metamodel and I m
>>surprised to see that the notification process is not really fast. On the
>>contrary, when I consider the view itself as a Adapter instead of the
>>editParts, the notification process is realley FASTER! why? I don't
>>understand! So it seems that if a class (my view for example) creates
>>EObjects, this class is more likely to be notifyed faster than the others
>>(edits pars) because it s that class which created the EObjects!
>>Surprising!
>>
>>So for this, I tried something else. Instead of directly attaching my
>>EObjects to the edits parts, I created Java classes (A Class Document and
>>class Tag). These java classes are linked to the edit parts, implement
>>Adapter (in order to get notifyed!) and contain a reference of a
>>corresponding EObject. When I click on the view, it modifies a metamodel's
>>EObject >>>> my java classes get notifyed and tell the edit parts to
>>update the view according to the corresponding EObject.
>>
>>And it's really fast, the view changes very quickly! But I don't want to
>>have this mess in my code. I want only one model (not the both like in
>>this case: emf EObjects + java classes!!)
>>
>>How can I do to resolve my problem??? Can you bring some explanations to
>>this behaviour?
>
>
>
When i remove the instruction "document.eContents()" placed in
part.getChildren() and I replace it by return Collection.EMPTY_LIST, the
behaviour is changing and it's really fast. However i don't call
refreshChildren()!!!that's very strange, I think it refreshes all the
10000 children without me to specify it!
Re: EMF and GEF: an interesting but strange result... [message #204984 is a reply to message #204951] Fri, 09 December 2005 13:35 Go to previous message
Eclipse UserFriend
Originally posted by: jkarlik.info.fundp.ac.be

karlik joachim a écrit :
> Randy Hudson a écrit :
>
>> There is no way to tell what is happening based on the description you
>> have given. The best guess I could make is that you are calling a
>> method like refreshChildren() in response to each eobject
>> notification. This method is not efficient. You should call addChild
>> or removeChild directly.
>>
>> "karlik joachim" <jkarlik@info.fundp.ac.be> wrote in message
>> news:dn9cuj$oui$1@news.eclipse.org...
>>
>>> I have noticed something really strange whith the use of GEF and EMF
>>> together. I have one Eclipse View which creates 10000 instances of a
>>> EObject (called tags) and put these instances in one EObject instance
>>> that I call the document. So a document containts 10000 tags. The
>>> content is passed to the graphicalEditPartViewer as usually. And the
>>> view is built like described in the GEF specification.
>>>
>>> So, Each edit part is linked directly to a EObject. (a tag or a
>>> document). My edits parts implement Adapter to get notified by a
>>> changement in the EMF metamodel (=the 10000 EObect instances create
>>> before by the view). Each edit part listens his associated EObject.
>>> (=the model object returned by getModel()).
>>>
>>> When I click on the view, I target a modification to the metamodel
>>> and I m surprised to see that the notification process is not really
>>> fast. On the contrary, when I consider the view itself as a Adapter
>>> instead of the editParts, the notification process is realley FASTER!
>>> why? I don't understand! So it seems that if a class (my view for
>>> example) creates EObjects, this class is more likely to be notifyed
>>> faster than the others (edits pars) because it s that class which
>>> created the EObjects!
>>> Surprising!
>>>
>>> So for this, I tried something else. Instead of directly attaching my
>>> EObjects to the edits parts, I created Java classes (A Class Document
>>> and class Tag). These java classes are linked to the edit parts,
>>> implement Adapter (in order to get notifyed!) and contain a reference
>>> of a corresponding EObject. When I click on the view, it modifies a
>>> metamodel's EObject >>>> my java classes get notifyed and tell the
>>> edit parts to update the view according to the corresponding EObject.
>>>
>>> And it's really fast, the view changes very quickly! But I don't want
>>> to have this mess in my code. I want only one model (not the both
>>> like in this case: emf EObjects + java classes!!)
>>>
>>> How can I do to resolve my problem??? Can you bring some explanations
>>> to this behaviour?
>>
>>
>>
>>
> When i remove the instruction "document.eContents()" placed in
> part.getChildren() and I replace it by return Collection.EMPTY_LIST, the
> behaviour is changing and it's really fast. However i don't call
> refreshChildren()!!!that's very strange, I think it refreshes all the
> 10000 children without me to specify it!

problem resolved.

Actually, My edit part called implicitely the method refreshChildren()
each time my edit part executed the method refreshVisuals.
I just overrided this method without specifying super.refreshChildren();
I put super.refreshChildren() on the activation of the edit part and it
seems to work. Thanks you!!
Previous Topic:back to default 'Select' tool after creating a connection
Next Topic:how to programatically select editpart on editorpage
Goto Forum:
  


Current Time: Thu Jan 16 23:09:21 GMT 2025

Powered by FUDForum. Page generated in 0.05891 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top