Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [jwt-dev] dynamic properties

Hi Marc,

Thank you very much for your feedback and great explanation of your ideas.

As you wrote, it would be better to implement a generic extension mechanism
to enrich model elements with  custom aspects instead of just adding dynamic
properties. If I got your idea about the open aspect element right, it would
be possible to use a generic, abstract EObject Aspect instead of a typed
Using this technique, the value field of a dynamic property could easily be
dynamically created as an EAttribute of the corresponding type.
(Concerning the typing issue, I've got a small comment: Maybe we should
consider to limit aspects to be subclassed from ModelElement, as is
everything else in the metamodel, since some routines in JWT may depend on
You wrote that a dynamically typed Aspect could not be extended with static
elements. Does this mean that a static class cannot be subclassed by
statically AND dynamically generated classes (e.g. the subclass
AbstractAspect>DynamicPropertyValue has to be created dynamically) ?

Also, I clearly forgot about the requirement to attach properties/aspects to
just some model elements. However, keeping in line with the metamodeling
approach, one could perceive an aspect as an addition to a metamodel element
which is then inherited by all instances. Basically I'm also thinking that
this could make the management of the aspects easier, since the general rule
would be: add it to all objects of this type ;)
Maybe a "switch" attribute could be considered to activate/deactivate it for
single objects with an additional possibility to set a default behavior on
the meta level.

Like you mentioned, the problem when loading a model without the required
metamodel extensions is certainly a problem that presents itself when using
this feature. When a completely dynamic extension is used, this renders the
model unloadable. However, loading dynamic properties without their external
description might just work if implemented as a static extension ;)

Applying the view management to aspects would certainly be a challenging
task. Of course, because I'm not quite familiar with the domains where
dynamic aspects will be used, I cannot decide how important this issue is,
but my subjective impression at the moment is that, if a user specifically
adds metamodel extensions, these don't necessarily have to be hidden (please
correct me if I'm wrong here, this just looks like a tempting opportunity to
skip a difficult issue).

Anyway, probably the best way to see how this can be implemented and to
detect additional difficulties, would be to just try out several different
approaches ;)


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: Mittwoch, 25. Juni 2008 12:13
An: Java Workflow Toolbox
Betreff: Re: [jwt-dev] dynamic properties

Hi Christian

Thanks for the research work you've done, this feedback, and the 
interesting solution you propose !

Nice info on the tabbed properties feature. OK, an adapter should do the 
thing, once the "rest' is ok.

About dynamic EMF : you're right, it has its limitations.

As you say, it is hard to create a dynamic extension of a static class. 
It should be doable nonetheless, but the question is : is it worth the 
effort (see below).

An important limitation is that dynamic and static subelements can't be 
mixed in a class, meaning that you can't extend an Action with a dynamic 
containment reference because Action may contain static Point subelements.

[actually, our ideas have a lot in common - see , and from now on I'll try to 
match them, ex. "DynamicProperty" / "Aspect"]

["properties" / "aspects" containment reference]
Therefore, and here it matches one of your conclusions, the right way of 
extending the jwt mm is to add a static containment reference where we 
want it to be extensible, in your case a "properties" containment 
reference that is typed DynamicProperty, and in my case a more open 
alternative consisting in an "aspects" one that is typed EObject (easy, 
open) or statically AspectImpl (if we want to bother with allowing to 
dynamically extend a static Aspect class ; note that being typed 
dynamically Aspect would forbid to statically extend it, which is a nice 

We agree that extending through such a containment reference also allows 
to manage "typed extension" i.e. a typed group of properties.

[external property description and "assigned model elements" / "profile"]
What you also crucially propose is a way to manage the consistency of 
which extended elements are allowed / available on which element. This 
is akin to what I termed "profile" in the jwt wiki. I didn't propose a 
functional or tech spec of it, and I like yours because it is simple. 
You do it through the cleverly external property description - I thought 
about putting this info in specific properties of the EMF model like 
EMF/XML does with ex. "xmlns:prefix", but your way has better separation 
of concern and more in line with the existing .

However it lacks some features ; for example it adds extended properties 
on all of its "assigned model elements", though the user would only want 
to be able to instanciate it on some of them (ex. only configure logging 
for some of them).

You also propose to manage versions, which I didn't first think of and 
which has been pointed at since. I agree that it has to be managed at 
the Model level i.e. at the whole extension level (and not extension 
element / property by extension element / property).

Comparison of both solutions : mine is more open, yours is better 
managed. So how about trying to merge it ? Actually, I think it can be 
done ^^ like this :

Merging both :

* Opening up the extension type i.e. using extensible Aspect rather than 
DynamicProperty is more flexible and would provide a extension 
mechanisme that is consistent from simple, dynamic extensions to 
complex, tree-like, static extensions.

* Your solution answers simple use cases very efficiently, but it can be 
implemented on top of mine (by providing in the core model a 
DynamicProperty that is a dynamic extension of Aspect) without losing 
its ease of use.

* Managing manage which extension is allowed where is paramount, and 
using an external metaconf file like yours is a nice idea that is in 
line with how views are handled today (as your "visible" feature on 
DynamicProperty confirms), and where we're trying to make them go (an 
eclipse plugin that not only manages views, but also other packaging and 
conf related issues like - surprise - extensions).

* I'd like to add in the external metaconf besides "assigned model 
elements" on DynamicProperty / Aspect the following metaproperties :
* "singleton" (meaning it's instanciated everywhere, like you spec'd ; 
if false the user will be able to add it using the newChild action),
* "removable" (false by default, so singleton by default wouldn't be 
removable, so a feature that may be activated and deactivated would be 
removable and not singleton).
* something like "emfType" / "instanceClassName" / Factory / emf 
extension file that tells what EMF type to instanciate rather than 
DynamicProperty, and that would by default by DynamicProperty

* your version management is great

* UI (ItemProviders) has to be adapted (maybe using Adapters) like you 
say and also to be able to instanciate types specified in the metaconf 
file. Views are already displayed in this kind of way, and I've tried 
some hacks on the getChildDescriptors method fueling the newChild 
command that tells me it is doable.

* the nowadays jwt-views app or future jwt-packager plugin will have to 
be able to manage metaconf files.

* the only thing that bugs me is that users WILL have to generate a view 
/ metaconf file to be able to use their extension. This would be nice 
because extended models could still be opened with only the ecore and 
not the metaconf.
* However, maybe that by "displaying and allowing to create" any other 
Aspect subtype "provided by in EMFs that are found in an autodiscovery 
directory" that "are not mentioned in the metaconf file" (just like what 
I advised for views), we could also achieve this goal ?
* or maybe we should just add an "export extended model" feature that 
would zip together the model, the extended ecores and the metaconf file, 
to be autodiscovered ;)

* a detail : if an extended workflow model is opened but its ecore 
extension is not found, nowadays JWT believes this to be an error due to 
the version of the workflow model file. So the version detection / 
update algorithm would have to be improved so it would be able to 
display a "missing extension ecore metamodel" in this case.

So what do you think ? Good enough for a try ? I for one have some time 
this week ^^


PS. about dynamically extending a static class :

First the extended static class can't be interface or abstract (which 
muddles the model), and secondly the model factory of its container (ex. 
for extending an Action, ProcessFactory, since it is the factory of 
Activity that is its container) must be able to handle creation of the 
extended static class, this way :

 org.eclipse.jwt.we.model.processes.ProcessesFactory extensionFactory = new
org.eclipse.jwt.we.model.processes.impl.ProcessesFactoryImpl() {
            public EObject create(EClass eClass)
               if ("LogAction".equals(eClass.getName())) {
                  org.eclipse.jwt.we.model.processes.Action action =
                  // the following is required to be able to access custom
LogAction features
                  // but it conflicts with Action static subelements ex.
Points -_- so doesn't work
                  return action;
               if ("Point".equals(eClass.getName())) {
               //return super.create(eClass);

Christian Saad a écrit :
> Hi,
> I’ve been looking a bit into the “dynamic properties” issue and I’d 
> like to share some early thoughts and experiences concerning this matter.
> First of all, the change of the properties view to a version that 
> supports multiple tabs (as described in 
> is quite simple. The “old” properties can be loaded into the view 
> using an adapter, so there is almost no additional effort to this 
> solution (see attachment). Concerning the new dynamic properties, 
> probably a similar approach can be used (write a propertypage that 
> reads the dynamic properties from the itemproviders, creates the 
> corresponding propertyeditors and can be fitted into the propertyview 
> using the same kind of adapter).
> To make the actual additions to the JWT metamodel, I’ve experimented a 
> bit with dynamic EMF. At first, it seemed that possibly the simplest 
> solution to extend existing classes would be to directly inject 
> dynamically created EAttributes or EReferences into the metaobjects 
> because in this case EMF would take care of most issues concerning the 
> management of the new items.
> However, I’ve learned that, sadly, it’s not possible to extend 
> existing static metaelements with dynamic structuralfeatures. It is 
> only allowed to create completely new dynamic classes or to subclass 
> existing static classes. Unfortunately this makes the whole process of 
> an almost automatic management of extensible metaelements quite 
> difficult (or maybe I’m just missing an obvious solution).
> The alternative would be to create a static metaelement for dynamic 
> properties as described in task 225704 and write code that simulates 
> the behavior of EMF EAttributes or EReferences using instances of this 
> class.
> I hope I got the basic idea that is behind this extension mechanism 
> right. To see if this is the case, I drew a small diagram outlining a 
> very concrete implementation of this extension of how I perceived the 
> problem (see attachment). Please correct me if I missed the point or 
> if this would be not viable solution.
> The basic idea is that dynamic properties are specified using a small, 
> external meta-model, in which a set of properties is part of a special 
> container element (just like Model is in the JWT metamodel). Sets of 
> dynamic properties can be serialized to and loaded from XMI files by 
> the user or created by Plugins using Eclipse extension points (being 
> converted into the corresponding properties model). This would 
> represent a generic interface to JWT.
> Once a set (or multiple sets) of dynamic properties is loaded into 
> JWT, it (they) can be added by the user to a model file. This means 
> that when selecting a ModelElement, the itemprovider searches all sets 
> of activated dynamic properties for properties that were declared for 
> this EClass-type and creates corresponding instances of 
> DynamicPropertyValue. The displaying of the dynamic properties can 
> done by the modified propertypage.
> Regards,
> Christian
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx

jwt-dev mailing list

Back to the top