|
Re: Test if EMF object is loading? [message #1755319 is a reply to message #1755301] |
Thu, 02 March 2017 10:25 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
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?...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
Re: Test if EMF object is loading? [message #1755488 is a reply to message #1755476] |
Fri, 03 March 2017 17:29 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
Re: Test if EMF object is loading? [message #1755705 is a reply to message #1755605] |
Tue, 07 March 2017 06:45 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
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;
}
Note the addition of "Gen" to the generated method. It's not so important in this case, but the body of this method will still be generated and it can be called from the overriding implementation of the getter. In this case, I'm essentially computing a default value for the feature if it's not been explicitly set.
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02947 seconds