[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [jwt-dev] dynamic properties
|
Hi Christian and all
I really think Christian's proposition is a very good one, however I did
not my nice page ( http://wiki.eclipse.org/JWT_Metamodel ) for nothing,
so I've tried to see where are the differences, and here is what I've
come up with !
Who needs to store typed information in JWT ?
* for small, user-originated needs, Christian's is perfect since it
is simple, efficient (since not dynamic), answers all requirements and
moreover doesn't need additional (ecore) metamodel file : if made using
EMF (which can also provide an easy way to a graphical editor),
Christian's metametamodel can even be bundled within a .workflow.
* for complex, vendor-originated needs, static ecore extension allow
to manage arbitrarily complex additional models. These extensions are
defined in plugin.xml and provided in vendor jars. Decoupling an
extension's metamodel (ecore file) from JWT's metamodel is done by
restraining extension on a given containment reference (like advised
before).
Now, how is this enough ?
* both can share the same type system, based on Christian's proposed
metametamodel, and possibly the same EMF containment reference typed by
a identical base class.
* for needs that are in between these two extremities... well, we'll
see later if there is still such need, if dynamic EMF can do something
about it, and if dynamic ecore resolution can be given a usable answer.
Actually that's the beauty of it, we'd still be able to do it ^^
On a less urgent note, some additional "nice to have" extension features
that have appeared since :
* customizing the property editor : done using a CustomPropertyEditor
(like Florian said to Mickaël). Should it be configured in the
plugin.xml or in the metametamodel ?
* customizing the "newChild" command list on a model element : for
example with two propertye extension on Action, this would allow to the
user which ones he want to see between "new Action," "new
CustomActionA", "new CustomActionB" and "new CustomActionAAndB".
Regards,
Marc
Marc Dutoo a écrit :
Hi Christian,
wow these are some very fruitful interactions indeed ^^
This has prodded me to improve http://wiki.eclipse.org/JWT_Metamodel ,
and to provide answers within your email below
Christian Saad a écrit :
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
DynamicProperty?
yes ! Obviously the default newChild commands should be removed in the
ItemAdapter (because it would allow to create any kind of element),
but if instantiation is controlled by your metametamodel it is already
the case.
I feel using only properties is too much of a constraint for vendors
whose features need complex configuration like Imixs or Nova Bonita
(see http://wiki.eclipse.org/JWT_Metamodel#Requirements )...
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
this).
I agree, that's what I did in my tests, and a meeting point with yours ;)
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) ?
Yeah, I know, those things are tricky ^^ Actually I'll need to redo
more specific tests, but I'm pretty sure a static class can only
contain static OR dynamic subelements but not both. What I mean is
that a dynamic extension of a static class can't contain static
subelements, even inherited ones. Ex. (tried) : a dynamic LogAction
extending the static Action type can't contain Points, because Points
will be parsed as DynamicEObjectImpl since they are underneath a
dynamic object, whereas Action.setValue(point) would like a PointImpl .
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.
I like keeping it simple ;) Your ideas have pushed me to detail the
requirements http://wiki.eclipse.org/JWT_Metamodel#Requirements . I
think this shows that two kind of aspects are required : those that
are like subtypes of existing model elements (ex. dynamic extension of
abstract Application, or on Action SCA runtime configuration,
properties configuring XPDL specific features...), and those that are
like transversal, additional features (ex. logging, Imixs.org Mail
tab...). The first we could call "singleton" and require to be
preinstanciated, the second we could call "feature" and let it be
activated/deactivated (looks like your switch).
Besides this, I like the idea of proposing additional "newChild"
commands configured to instanciate a model element with a configured
list of "singleton" (preinstanciated) Aspects, but this is on the UI
level and not on the model level anymore. This will allow to
instanciate different kind of dynamic Applications. What I mean is, ok
for preinstanciation since it simplifies things, but in this case
having only one "newChild" command for each static model element does
not give enough flexibility : rather, more should be configurable with
different singletons... What do you think ?
Finally, I fear that adding dynamic extensions everywhere by default
would be a risk for performances... Though I agree your static
solution would not be a problem in this case.
I've summed it up here
http://wiki.eclipse.org/JWT_Metamodel#specifications . Still thinking
it up...
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 ;)
Yep, though their metametamodel has to be found ;) by the way, the
metametamodel could even be inlined in the .workflow file if it is
built in EMF...
That's why your proposition should also be done.
I've tried to list all ways here
http://wiki.eclipse.org/JWT_Metamodel#Metamodel_extensions_and_JWT_WE_-_finding_and_loading_models_and_ecores
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).
Yep, displayObject() returns true if the object is not found in the
view (tried it) ^^
In my mind view management and your metametamodel (which also controls
extension behaviour and display) would nicely merge together...
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 ;)
Regards,
Christian
-----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
http://wiki.eclipse.org/JWT_Metamodel , 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 possibility).
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).
[versions]
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 ^^
Regards,
Marc
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() {
@Override
public EObject create(EClass eClass)
{
if ("LogAction".equals(eClass.getName())) {
org.eclipse.jwt.we.model.processes.Action action =
createAction();
// 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
((org.eclipse.jwt.we.model.processes.impl.ActionImpl)
action).eSetClass(eClass);
return action;
}
if ("Point".equals(eClass.getName())) {
return
org.eclipse.jwt.we.model.view.impl.ViewFactoryImpl.eINSTANCE.create(eClass);
}
//return super.create(eClass);
return
org.eclipse.jwt.we.model.processes.impl.ProcessesFactoryImpl.eINSTANCE.creat
e(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
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
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
Regards,
Marc
