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

[Ed Merks <Ed.Merks@xxxxxxxxx>]

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?  Perhaps that's the last 
comment in the bug.  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.

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 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.  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.
> Regards,
> Mickael