| Test if EMF object is loading? [message #1755301] |
Thu, 02 March 2017 03:54  |
Eclipse User |
|
|
|
Hello,
At several place, I have absolutely to detect if an EMF object is loading or not.
Example 1: in business method
The following method cannot work during loading, because property1 is maybe not correctly set. When running of course, it works.
@Override
public void setProperty2(Double property2) {
if (getProperty1()="toto")
return;
.....
}
Example 2: in TotalObserver
I use this code to prevent my observer to react to each change. Is it a correct way to do?
public TotalObserver(MyObject theObservedObject) {
super();
this.theObservedObject = theObservedObject;
setAdapter(new EContentAdapter() {
public void notifyChanged(Notification notification) {
super.notifyChanged(notification);
Resource resource = eResource();
if (resource==null)
return;
if (resource != null && ((Resource.Internal) resource).isLoading()){
System.out.println("We are loading");
return;
}
if (resource != null && ((Resource.Internal) resource).isLoaded()){
System.out.println("Resource is loaded");
}
Thx for your help
Rgds
Jim
|
|
|
| Re: Test if EMF object is loading? [message #1755319 is a reply to message #1755301] |
Thu, 02 March 2017 05:25  |
| Eclipse User |
|
|
|
In terms of your derived setter, it's probably just a bad design. The behavior of course generally depends on the order in which setProperty1 and setProperty2 are called. That just doesn't seem good because any code written against this API will behave unexpectedly. I also wonder about the == test on a string, but likely that's just an artifact of a synthetic example. And in the end, I don't see why loading matters. If you serialized property2, it should be set as it was serialized. If property1 has some special value, then that was serialized too, but how can the serialization be in a state where on deserializing you really want to ignore setting the value, even though if you did it programmatically you won't ignore it. I just don't get it...
For example 2, I also don't understand the problem being solved. E.g., it seems simple not to attach the observer until you've loaded the resource. When/where are you attaching this observer? Perhaps using org.eclipse.emf.ecore.xmi.XMLResource.OPTION_DEFER_ATTACHMENT so that the object isn't attached to the resource until it's fully loaded would avoid the whole issue? But it's still a question of, when are you adding the adapter?...
|
|
|
|
|
|
| Re: Test if EMF object is loading? [message #1755488 is a reply to message #1755476] |
Fri, 03 March 2017 12:29 |
| Eclipse User |
|
|
|
You can obviously do whatever you like, but anyone using the API to set a value will be surprised that setting a value is just ignored. The end user of a UI would also be better off to see the property be read-only rather than setting it and having it be ignored. But that's just my opinion. It's clear this is already causing difficulties. It's also clear that one could set the cost, and then set the production plant afterward, and I'm not sure you've also implemented special logic to unset the cost in that case as well. A different approach would be to define constraints on the model so that this is validated as an invalid state. In the generated editor, with live decoration, this would be displayed to the end user as soon as they've done something to put the model into an invalid state.
So the observer is used to keep derived feature values up-to-date. You could more simply compute the value on-demand instead. In any case, the value isn't needed until you've asked for it, so as an alternative, you could attach the observer only when a derived feature's value is requested. Presumably the derived features are marked as derived in the model (so EcoreUtil.copy doesn't copy them), and are also marked as transient (so they're not serialized). This avoids the whole problem of having to know something about how the model is being constructed by a deserializer or a copier.
|
|
|
|
|
| Re: Test if EMF object is loading? [message #1755705 is a reply to message #1755605] |
Tue, 07 March 2017 01:45 |
| Eclipse User |
|
|
|
For example 1, I did already explain how you can disable properties in the properties view by specializing the item property descriptor's canSetProperty method.
For example 2, the value is displayed based on calling the getter on the implementation class. So no computation needs to be done until the getter is called the first time. You can specialize the getter code. Here's a simple example /**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public String getNameGen()
{
return name;
}
public String getName()
{
String name = getNameGen();
if (StringUtil.isEmpty(name))
{
String version = getVersion();
if (!StringUtil.isEmpty(version))
{
return "JRE for " + version;
}
return null;
}
return name;
}
I'm suggesting that the getter might well be the best place to do any initial computation and to attach adapters to keep that computation up-to-date.
The option org.eclipse.emf.ecore.xmi.XMLResource.OPTION_RESOURCE_HANDLER can be used to perform actions before/after load/save.
|
|
|
Powered by
FUDForum. Page generated in 0.09286 seconds
Home