Home » Modeling » EMF » bugs 240299 and 240502: interesting for EMF?
| bugs 240299 and 240502: interesting for EMF? [message #423168] |
Wed, 24 September 2008 09:55  |
|
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 ;)
Regards,
Mickael
|
|
|
| Re: bugs 240299 and 240502: interesting for EMF? [message #423177 is a reply to message #423168] |
Wed, 24 September 2008 11:55  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: bugs 240299 and 240502: interesting for EMF? [message #423180 is a reply to message #423177] |
Wed, 24 September 2008 13:43 |
|
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
|
|
|
| Re: bugs 240299 and 240502: interesting for EMF? [message #423184 is a reply to message #423180] |
Wed, 24 September 2008 14:27 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Mickael,
Comments below.
Mickael Istria wrote:
> 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 -).
I see. That makes good sense.
>
>
>> 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).
Overriding within a subclass. Hmmm...
> 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.
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...
>
> We are not trying to change CellEditor according to DataType, but
> according to the "business" meaning of the feature in our 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...
>
> 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".
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.
> 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...
>
> 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'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...
>
> I've been thinking about it, and I don't have ideas about how to
> ensure that extension respect integrity constraints.
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.
>
>
>
>
>> 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.
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.
>
> 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).
Yep, that sounds like what I would call a derived feature.
> In this case Parameters is what I called the "computed property".
> Is it what you call a "derived feature"?
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...
>
> Indeed, bug 216701 seems to have the same goal, am I right?
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...
>
>> 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.
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.
>
>> 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.
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?
>
>
>
> Mickael
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 08:50:25 GMT 2024
Powered by FUDForum. Page generated in 0.02987 seconds |
] 
Search
Help
Register
Login
Home
