| [jwt-dev] dynamic properties |
|
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 http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html)
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 |
Attachment:
tabbedproperties.png
Description: PNG image
Attachment:
dynamicproperties.png
Description: PNG image
