[news.eclipse.tools.emf] Re: bugs 240299 and 240502: interesting for EMF

[Mickael Istria <mickael.istria@xxxxxxxxxxx>]

Hi Ed,

Thanks for your answers, I added comments below.

Ed Merks a écrit :
> Mickael,
>
> Comments below.
>
>
> Mickael Istria wrote:
> > 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 ;)
> 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? 

Actually, extensions are registered for a feature *of a class* 
(Extension point contains package, className and featureName - ID, not 
displayed -).


> 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).
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.

We are not trying to change CellEditor according to DataType, but 
according to the "business" meaning of the feature in our model.

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.

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...

I've been thinking about it, and I don't have ideas about how to ensure 
that extension respect integrity constraints.




> 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.

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).
In this case Parameters is what I called the "computed property".
Is it what you call a "derived feature"?

Indeed, bug 216701 seems to have the same goal, am I right?

> 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.

> 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