Home » Modeling » EMF » Generated editor loads content too early
| |
| Re: Generated editor loads content too early [message #428832 is a reply to message #428827] |
Tue, 31 March 2009 14:21   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Some things to add:
>
> Tried to detect that the didAdd() method is called in the course of
> deserializing.
It will happen during copying as well...
> Retrieved the Resource object from the passed in newObject argument
> and debugging revealed two protected member variables
> "isLoading" and "isLoaded". Both have the value true which appears
> quite contradictous to me.
The variable is set early to eliminate the possibility that you might
recursively cause the resource to be loaded while it's loading. The
notification doesn't go out until the loading is complete though, so
external observers should generally see the actual loaded resource.
> isLoading = true may be a candidate to find out whether we are in the
> course of deserializing but unfortunately this variable has no getter.
You didn't notice Resource.Internal.
> isLoaded has a getter but its value is useless.
If you have an object that's in a resource, you can definitely expect
this value to be true, so it will not serve your purpose at all.
>
> Is there any other simple method to distinct getter/setter calls that
> happen during deserialisation from those caused by editing actions?
The nature of the question seems problematic because EcoreUtil.copy will
generally be much like deserialization, so whatever problem you fix is
likely to resurface.
>
> Regards,
> Dirk
>
> Dirk Hoffmann schrieb:
>> Hi,
>>
>> for our project we're still using the editor generated by the EMF
>> code generation tools. Now we're faced with the following problem:
>>
>> In order to get notified about a reference being added to an EList
>> object we changed the getter of the EList to
>>
>> public EList getHasNContexts() {
>> if (hasNContexts == null) {
>> // was: hasNContexts = new EObjectResolvingEList(...
>> hasNContexts = new NotifyingList(
>> Context.class,
>> this,
>> SbqPackage.QUERY_NODE__HAS_NCONTEXTS);
>> }
>> return hasNContexts;
>> }
>>
>> where NotifyingList is a local class extending EObjectResolvingEList
>> like so:
>>
>> private class NotifyingList extends EObjectResolvingEList {
>> protected void didAdd(int index, Object newObject) {
>> // Get runtime representation of the context
>> RuntimeContext ctx = Registry.obtain(
>> (Context)newObject
>> );
>> // do something with ctx
>> }
>> }
>>
>> i.e. we replaced the EList implementation with our own version and
>> that overrides the didAdd method.
>>
>> What we want to achieve is to obtain some object from a Registry in
>> the course of the didAdd() method being called and thats the point
>> where the problem arises:
>>
>> The Registry is supposed to be filled through another plugin in the
>> course of running its IStartup.earlyStartup() method. This method
>> gets called independent of a Bundle activator because we extend the
>>
>> org.eclipse.ui.startup
>>
>> extension point and specify the class that implements the IStartup
>> interface.
Of course it's generally bad to do early startup as well...
>>
>> Everything is fine when I start the editor and then open a file in
>> the generated editor. Things go wrong when I terminate the editor
>> with the file being opened and then restart it. Now the file
>> apparently gets deserialized and the didAdd() method gets called. And
>> this happens *before* the IStartup.earlyStartup() gets called.
It seems odd to me that earlyStartup should happen so late. I also
don't understand why your bundle's regular start doesn't initialize the
registry. Given a dependency on such a bundle, the bundles
initialization should be done long before anyone depending on it can see it.
>>
>> This seems weird to me as I explicitely asked the
>> IStartup.earlyStartup() to be called upon eclipse starting up but the
>> loading of the file still happens before that.
It's definitely weird. But I don't even understand why you need
earlyStartup. EMF has all kinds of registries that must be populated
before any other EMF-based plugins will work properly, yet we have no
need for early startup...
>>
>> Anybody any ideas?
>>
>> Regards,
>> Dirk
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generated editor loads content too early [message #428889 is a reply to message #428832] |
Wed, 01 April 2009 13:26 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Hi,
thanks to Ed for the prompt reply; I wonder how much time he spends each
day to answer all the questions from the EMF users.
See below for comments.
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Some things to add:
>>
>> Tried to detect that the didAdd() method is called in the course of
>> deserializing.
> It will happen during copying as well...
Ah, never thought of this but I believe we can live with that.
>> Retrieved the Resource object from the passed in newObject argument
>> and debugging revealed two protected member variables
>> "isLoading" and "isLoaded". Both have the value true which appears
>> quite contradictous to me.
> The variable is set early to eliminate the possibility that you might
> recursively cause the resource to be loaded while it's loading. The
> notification doesn't go out until the loading is complete though, so
> external observers should generally see the actual loaded resource.
>> isLoading = true may be a candidate to find out whether we are in the
>> course of deserializing but unfortunately this variable has no getter.
> You didn't notice Resource.Internal.
Another "Ah". Meanwhile I had coded a cast to ResourceImpl but changed
that now to Resource.Internal; guess that's the official way to access
that piece of information. The isLoading attribute is the right one to
detect the deserialization context.
>> isLoaded has a getter but its value is useless.
> If you have an object that's in a resource, you can definitely expect
> this value to be true, so it will not serve your purpose at all.
>>
>> Is there any other simple method to distinct getter/setter calls that
>> happen during deserialisation from those caused by editing actions?
> The nature of the question seems problematic because EcoreUtil.copy will
> generally be much like deserialization, so whatever problem you fix is
> likely to resurface.
>>
>> Regards,
>> Dirk
>>
>> Dirk Hoffmann schrieb:
>>> Hi,
>>>
>>> for our project we're still using the editor generated by the EMF
>>> code generation tools. Now we're faced with the following problem:
>>>
>>> In order to get notified about a reference being added to an EList
>>> object we changed the getter of the EList to
>>>
>>> public EList getHasNContexts() {
>>> if (hasNContexts == null) {
>>> // was: hasNContexts = new EObjectResolvingEList(...
>>> hasNContexts = new NotifyingList(
>>> Context.class,
>>> this,
>>> SbqPackage.QUERY_NODE__HAS_NCONTEXTS);
>>> }
>>> return hasNContexts;
>>> }
>>>
>>> where NotifyingList is a local class extending EObjectResolvingEList
>>> like so:
>>>
>>> private class NotifyingList extends EObjectResolvingEList {
>>> protected void didAdd(int index, Object newObject) {
>>> // Get runtime representation of the context
>>> RuntimeContext ctx = Registry.obtain(
>>> (Context)newObject
>>> );
>>> // do something with ctx
>>> }
>>> }
>>>
>>> i.e. we replaced the EList implementation with our own version and
>>> that overrides the didAdd method.
>>>
>>> What we want to achieve is to obtain some object from a Registry in
>>> the course of the didAdd() method being called and thats the point
>>> where the problem arises:
>>>
>>> The Registry is supposed to be filled through another plugin in the
>>> course of running its IStartup.earlyStartup() method. This method
>>> gets called independent of a Bundle activator because we extend the
>>>
>>> org.eclipse.ui.startup
>>>
>>> extension point and specify the class that implements the IStartup
>>> interface.
> Of course it's generally bad to do early startup as well...
>>>
>>> Everything is fine when I start the editor and then open a file in
>>> the generated editor. Things go wrong when I terminate the editor
>>> with the file being opened and then restart it. Now the file
>>> apparently gets deserialized and the didAdd() method gets called. And
>>> this happens *before* the IStartup.earlyStartup() gets called.
> It seems odd to me that earlyStartup should happen so late. I also
> don't understand why your bundle's regular start doesn't initialize the
> registry. Given a dependency on such a bundle, the bundles
> initialization should be done long before anyone depending on it can see
> it.
Tried that when running my feature from within the ide and also as a
feature built, packed and dropped into another Eclipse installation.
Observed the same effect in both situations. By the way: Using EMF 2.2.4
with Eclipse 3.2.2 for developing and also tested the feature with
Eclipse 3.3.2 and EMF 2.3.0.
The reason for the IStartup.earlyStartup() is that I want to be able to
simply drop that plugin into the plugins directory and have it register
some objects with a Registry provided by another plugin upon startup.
Maybe this is not the right approach; I guess the Registry plugin should
provide an extension point which the plugin that registers stuff would
then implement. It's just that I haven't got into that extension point
stuff up to date.
>>>
>>> This seems weird to me as I explicitely asked the
>>> IStartup.earlyStartup() to be called upon eclipse starting up but the
>>> loading of the file still happens before that.
> It's definitely weird. But I don't even understand why you need
> earlyStartup. EMF has all kinds of registries that must be populated
> before any other EMF-based plugins will work properly, yet we have no
> need for early startup...
>>>
>>> Anybody any ideas?
>>>
>>> Regards,
>>> Dirk
|
|
|
| Re: Generated editor loads content too early [message #428893 is a reply to message #428889] |
Wed, 01 April 2009 13:49 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000509090902090606000208
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Hi,
>
> thanks to Ed for the prompt reply; I wonder how much time he spends
> each day to answer all the questions from the EMF users.
A scary amount of time, though not as much as you might think. I have a
formula to speed it up as described at the end of this blog:
< http://ed-merks.blogspot.com/2008/10/service-and-support-fue l-for-your.html>
http://ed-merks.blogspot.com/2008/10/service-and-support-fue l-for-your.html
>
> See below for comments.
>
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>> Dirk Hoffmann wrote:
>>> Some things to add:
>>>
>>> Tried to detect that the didAdd() method is called in the course of
>>> deserializing.
>> It will happen during copying as well...
> Ah, never thought of this but I believe we can live with that.
>>> Retrieved the Resource object from the passed in newObject argument
>>> and debugging revealed two protected member variables
>>> "isLoading" and "isLoaded". Both have the value true which appears
>>> quite contradictous to me.
>> The variable is set early to eliminate the possibility that you might
>> recursively cause the resource to be loaded while it's loading. The
>> notification doesn't go out until the loading is complete though, so
>> external observers should generally see the actual loaded resource.
>>> isLoading = true may be a candidate to find out whether we are in
>>> the course of deserializing but unfortunately this variable has no
>>> getter.
>> You didn't notice Resource.Internal.
> Another "Ah". Meanwhile I had coded a cast to ResourceImpl but changed
> that now to Resource.Internal; guess that's the official way to access
> that piece of information.
Yes.
> The isLoading attribute is the right one to detect the deserialization
> context.
Yes, Kenn Hussey really wanted it for UML a long time ago.
>>> isLoaded has a getter but its value is useless.
>> If you have an object that's in a resource, you can definitely expect
>> this value to be true, so it will not serve your purpose at all.
>>>
>>> Is there any other simple method to distinct getter/setter calls
>>> that happen during deserialisation from those caused by editing
>>> actions?
>> The nature of the question seems problematic because EcoreUtil.copy
>> will generally be much like deserialization, so whatever problem you
>> fix is likely to resurface.
>>>
>>> Regards,
>>> Dirk
>>>
>>> Dirk Hoffmann schrieb:
>>>> Hi,
>>>>
>>>> for our project we're still using the editor generated by the EMF
>>>> code generation tools. Now we're faced with the following problem:
>>>>
>>>> In order to get notified about a reference being added to an EList
>>>> object we changed the getter of the EList to
>>>>
>>>> public EList getHasNContexts() {
>>>> if (hasNContexts == null) {
>>>> // was: hasNContexts = new EObjectResolvingEList(...
>>>> hasNContexts = new NotifyingList(
>>>> Context.class,
>>>> this,
>>>> SbqPackage.QUERY_NODE__HAS_NCONTEXTS);
>>>> }
>>>> return hasNContexts;
>>>> }
>>>>
>>>> where NotifyingList is a local class extending
>>>> EObjectResolvingEList like so:
>>>>
>>>> private class NotifyingList extends EObjectResolvingEList {
>>>> protected void didAdd(int index, Object newObject) {
>>>> // Get runtime representation of the context
>>>> RuntimeContext ctx = Registry.obtain(
>>>> (Context)newObject
>>>> );
>>>> // do something with ctx
>>>> }
>>>> }
>>>>
>>>> i.e. we replaced the EList implementation with our own version and
>>>> that overrides the didAdd method.
>>>>
>>>> What we want to achieve is to obtain some object from a Registry in
>>>> the course of the didAdd() method being called and thats the point
>>>> where the problem arises:
>>>>
>>>> The Registry is supposed to be filled through another plugin in the
>>>> course of running its IStartup.earlyStartup() method. This method
>>>> gets called independent of a Bundle activator because we extend the
>>>>
>>>> org.eclipse.ui.startup
>>>>
>>>> extension point and specify the class that implements the IStartup
>>>> interface.
>> Of course it's generally bad to do early startup as well...
>>>>
>>>> Everything is fine when I start the editor and then open a file in
>>>> the generated editor. Things go wrong when I terminate the editor
>>>> with the file being opened and then restart it. Now the file
>>>> apparently gets deserialized and the didAdd() method gets called.
>>>> And this happens *before* the IStartup.earlyStartup() gets called.
>> It seems odd to me that earlyStartup should happen so late. I also
>> don't understand why your bundle's regular start doesn't initialize
>> the registry. Given a dependency on such a bundle, the bundles
>> initialization should be done long before anyone depending on it can
>> see it.
> Tried that when running my feature from within the ide and also as a
> feature built, packed and dropped into another Eclipse installation.
> Observed the same effect in both situations. By the way: Using EMF
> 2.2.4 with Eclipse 3.2.2 for developing and also tested the feature
> with Eclipse 3.3.2 and EMF 2.3.0.
>
> The reason for the IStartup.earlyStartup() is that I want to be able
> to simply drop that plugin into the plugins directory and have it
> register some objects with a Registry provided by another plugin upon
> startup.
Doesn't that other plugin have extension points?
> Maybe this is not the right approach; I guess the Registry plugin
> should provide an extension point which the plugin that registers
> stuff would then implement. It's just that I haven't got into that
> extension point stuff up to date.
Indeed. It's best for everything to be on-demand/lazy...
>>>>
>>>> This seems weird to me as I explicitely asked the
>>>> IStartup.earlyStartup() to be called upon eclipse starting up but
>>>> the loading of the file still happens before that.
>> It's definitely weird. But I don't even understand why you need
>> earlyStartup. EMF has all kinds of registries that must be populated
>> before any other EMF-based plugins will work properly, yet we have no
>> need for early startup...
>>>>
>>>> Anybody any ideas?
>>>>
>>>> Regards,
>>>> Dirk
--------------000509090902090606000208
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dirk,<br>
<br>
Comments below.<br>
<br>
Dirk Hoffmann wrote:
<blockquote cite="mid:gqvq2o$3tp$1@build.eclipse.org" type="cite">Hi,
<br>
<br>
thanks to Ed for the prompt reply; I wonder how much time he spends
each day to answer all the questions from the EMF users.
<br>
</blockquote>
A scary amount of time, though not as much as you might think.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 15:47:55 GMT 2024
Powered by FUDForum. Page generated in 0.03482 seconds |
] 
Search
Help
Register
Login
Home
