| [news.eclipse.tools.emf] Re: bugs 240299 and 240502: interesting for EMF? |
Mickael,
Comments below.
I see. That makes good sense.Hi Ed,
Thanks for your answers, I added comments below.
Ed Merks a écrit :Mickael,
Comments below.
Mickael Istria wrote:I've not looked at the details of 240499, but it does seem interesting. In 2.4 we made some changes so that the property ID would be the untranslated feature name rather than being just the display name. I wonder though if registering against the ID is sufficient given that the ID is unique only with a given class?Hello,
In JWT, we've been working on 2 features for the JWT workflow editor (which is based on EMF), and it seems to me that they are more generic than JWT context.
Those feature are
* An extension point allowing to set a custom PropertyDescriptor in property sheet for specified EMF feature (to facilitate the input of properties for end-users) (bug 240499)
* An extension point that allows to add a INotifyChangedListener on specified feature (we currently use it for value validation, and to compute some properties automatically) (bug 240502)
Some documentation is available on bugzilla entries and on items 2.7 and 2.8 of wiki page http://wiki.eclipse.org/index.php?title=JWT_Extensions
We think that such features could be interesting for EMF generally, that's why I spot them out (bug 240499 is closed to bug 205432).
If you think that they deserve to become part of EMF, we would be pleased to participate to their integration in EMF. If you think that they would not fit in EMF, sorry for the spam ;)
Actually, extensions are registered for a feature *of a class* (Extension point contains package, className and featureName - ID, not displayed -).
Overriding within a subclass. Hmmm...
Perhaps that's the last comment in the bug.
The last comment of the bug is about overriding propertyDescriptors when a propertyDescriptor is defined on a feature of a class, and that another one is defined on the same feature of a subclass (then we want the subclass to use the second property editor instead of its parent's one).
For features based on Enums or EReferences we do that by default already. Generally a client can override their item property descriptor to specialize the result of getChoiceOfValues and by doing so, automatically get a combo box with those choices...This case is now OK (the limitation does not exist any more)
Generally I imagine the most important point is to be able to specialize the cell editor, which is certainly possible if you can create a specialized property descriptor and that approach is perhaps a bit more general as well. Currently the cell editor is determined by the multiplicity of the feature and the type of the feature. I would imagine this is quite a common pattern for specialization to be based on the data type of the attribute. At the same time, I imagine that someone might register something against one of Ecore's data types and then inject their specialization into all applications. Another possible approach would be to annotate the Ecore model itself to indicate that a specific extension for editing that property is desired. In some ways this might seem like polluting the modeling with visualization details, but at the sametime, it's something that would support specializations even for generated models... Clearly I'm a little torn on the best design. I'm very interested in your ideas and incorporating something generally useful in EMF itself for 205432.
You're right, current implementation of this features allows to use propertyDescriptor and CellEditors that do not respect DataTypes and Multiplicity.
I did not thought about that kind bad uses.
In our use cases, we simply used the extension to replace basic String editors by more clever widgets such as comboBox when to set of consistent values can be guessed from current model.
Often such business meaning could be captured by defining an EDataType for it and then all features of that type can be edited in a common way. This could reduce the number of registrations required...
We are not trying to change CellEditor according to DataType, but according to the "business" meaning of the feature in our model.
This seems the perfect thing for which to define an EDataType. You might then define a more specialized data structure that converts to and from a String for serialization purposes. And even if the EDataType is just wrapper for java.lang.String, you could define constraints on it to enforce that it's well formed for this specific use case.
For example, the JWT metamodel contains an Application class, that is made of attribute "class" that is aimed to contain the name of a class (String), and "method" (String). On eof our use case is to replace the text input for "method" by a combobox containing all available methods that we guessed from "className".
As you understood, this custom property descriptor can not be generalized to any String feature.That would be bad. But you could define a specialized EDataType. Think of some of the EDataTypes in the XMLTypePackage for example, like NCName...
I'm not sure I understand the comment. Certainly we've added many integrity constraints to the Ecore model, i.e., the whole EcoreValidator is new to EMF 2.3, without destabilizing the downstream people that depend on it...
Moreover, we want our metamodel to be stable, since some people may depend on it. Thus we can't add integrity constraints to the metamodel only to improve UI...
Generally such constraints are enforced by a separate validation phase. So a feature of type NCName might well contain a bad value, but that bad value is detectable and can be brought to the user's/client's attention.
I've been thinking about it, and I don't have ideas about how to ensure that extension respect integrity constraints.
A feature who's value is derived from the values of other features. E.g., a feature's value might be the sum of the values of two other features.
It seems to me that 240499 is very closely related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701, but I'm not sure if these computed properties you mention are effectively derived features.
I don't know what exactly means "derived features", thus I will answer you with an example.
Yep, that sounds like what I would call a derived feature.
In our use case, we have that class Application that also contains a List of Parameters (another JWT Model Class). What I am talking about is the fact that when I change the method, the extension I added on notification automatically finds the method signature and sets the Parameters according to it (when method can be resolved in JAva).
Features marked as derived are not copied by EcoreUtil.copy, since their value is purely derived from other things that are copied. And typically derived features are transient since it's kind of pointless to save them. Often they are make not changeable so the client can't directly set the value; often they aren't though, since the derivation process itself may want to set them...In this case Parameters is what I called the "computed property". Is it what you call a "derived feature"?
Yes, and the idea is that you can control the creation of the setting delegate used to implement the derived feature. One might have very general ones, like the one in the bugzilla that's based on specifying a path for how to navigate to the derived value. But it could also be very specific such that it's only use for one particular feature with all kinds of specialized logic just for that case...
Indeed, bug 216701 seems to have the same goal, am I right?
In this case, it's done more at the data binding level (i.e., in the UI) rather than as an intrinsic part of the model. It sounds like your case is more a model intrinsic thing.
I could certainly imagine that as part of computing the derived value the first time you'd attach listeners to the objects involved in the computation of the value and then response to notifications on features of those objects to update the derived value and even to fire a notification for that change. The work on https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130 might not seem related at all, but I think it's related too because the data binding folks have this notion of a computed property and can use these pre-read callbacks to track all the objects access as part of computing a derived property's value and therefore can automatically add adapters to all those objects so that when any of the objects changes, they know to recompute the property.
Yes, it seems to be the same generic issue of adding behavior.
I'm very interested in the property descriptor stuff you've done. What do you think of an approach whereby the feature or perhaps the data type specifies an EAnnotation with a specific source, e.g., http:///org/eclipse/emf/edit/ui and then a key-value pair, e.g., propertyDescriptor -> <someURI> and then your registration would be against <someURI>. When creating a property descriptor, we'd look for this annotation on the feature, and failing finding it, on the feature's type, we'd use the <someURI> value to look up a property descriptor factory a registry of such things, and use that to create the property descriptor. This seems perhaps maximally flexible and would allow folks to specialize how property descriptors are support. Perhaps an alternative that would work only for generated models would be to specify the <someURI> as a property on a GenFeature (and even the GenClassifier) and then pass it in as data for the ItemPropetyDescriptor... This seems a little better as a separation of concerns... Does anyone else have opinions on this?
The extended validation framework already has extensive support for registering constraints that are extrinsic to the model (as opposed to EMF's generated EValidator which is useful for defining constraints that are intrinsic to the model), so likely you'd want to reuse one of these two things for validation purposes.
The extended validation framework seems to be something that covers a part of the purpose of our plugin, I'll investigate on it to find how to use it well in our context.
Mickael