Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] AW: Making new JWT metamodel elements visible in the JWT WE UI


Please find some improvements and additions (marked "added 20080527") at , mainly samples and WE need analysis.

Florian, Christian, thank you very much for your feedback. I believe you'll find the new samples a bit more explicit. I'll add more & screenshots, as well as a bugzilla as soon as possible.


First thanks for your explanation on JWT Views. As you'll see it has been useful ^^

About the update algorithm, indeed, I've encountered some problems already, though not major. I'm plenty OK with the "addition only" limitation.

About the View concept (which is nice, as Miguel reminded me ;), you'll find some propositions in the wiki above. In a first time, we can simply show all extensions by making Views.displayObject() return true if the model object type can't be found in the view file is an acceptable behaviour.

About limits of extension and GEF, thanks for the more detailed analysis.

About extension loading among the various files, EMF has a lot of nice out of the box features. For example, an EMF that refers relatively to an ecore extension will load right ! However a limitation is that "unknown" extension ecores are not available, implying that a mechanism like your suggested ecore directory would be nice. And vendors will want to be able to have a more built-in (read : plugin.xml) way to provide their ecore extensions.

About versioning extensions, nice one ! I add it to the requirement list.

Visual representation is majorly impacted by extensions, as well as other components : transformations, and even runtime (wam) libraries and tools.

Concerning aspects with further inner elements, they are nicely displayed in a tree manner by the JWT outline, and the palette provides by default creation tools.


Christian Saad a écrit :
Hi Marc,

Some thoughts of mine concerning the JWT meta model extension:

a basic problem with all extensions to the meta model at the moment is the
update algorithm, that requires backward compatibility, i.e. additions are
allowed, removing or moving elements isn't. But since this is a quite
unsatisfiable limitation, this should be changed in the near future anyway.

The view concept is also a (small) aspect, which must be changed so model
elements for which no entry exists in the view files are displayed by

As you've already written in the wiki page, a graphical representation of
additions using GEF would require very much effort, if it is even possible.
Basically the only way I can think of right now would be, if the element is
part of an activity, e.g. like an Action or a Reference (but without
graphical connections), perhaps with a user defined icon.

Unfortunately, I have no experience with dynamic extensions to EMF but this
technology sounds interesting. If I got your idea right (I hope) the
ModelElement object should be extended with a relation to *-aspects, which,
in turn, represent an interface for model extensions?
One question that arises concerning the implementation of this feature is
the nature of the integration of vendor specific extensions into the model.
I assume, that they are being kept in separate files, so probably a standard
directory should be introduced, where all locally available extensions are
saved and loaded on demand. This would require a naming and versioning
mechanism for extensions (a list of which must be centrally stored in the
model file, e.g. in the model-element) to ensure compatibility, and also a
certain kind of tolerance of the loading mechanism if the needed extension
is not available.
Another point which occurs to me is the visual representation of the
aspects, which, if I didn't get it wrong, is probably limited to the
properties view. Would it be sufficient if the standard editors provided by
EMF, e.g. for string or integer input, are used? This technique would
however probably reach its limits, if an aspects has more than one layer,
i.e. it contains child objects, or of course, if the supplier of the
extension wants to include his own property editor.


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Montag, 19. Mai 2008 18:00
An: Christian Saad
Cc: 'Florian Lautenbacher'; csaad@xxxxxxx; Java Workflow Toolbox
Betreff: Making new JWT metamodel elements visible in the JWT WE UI

Thanks very much Christian & Florian, this is what I needed ^^

About the extension spec, it is still a work in progress, I wanted to share where I was going to. I'm sure you'll have valuable input on the different alternatives as well !


Christian Saad a écrit :
Hi Marc,

the visibility of the model elements is controlled by the JWT views
If you alter the meta model, the view files (business.view, technical.view
in the views dir) have to be adapted to the new meta model elements.
Unfortunately, this means you'll have to completely recreate both view
with the jwt-view tool (which can be found on the eclipse cvs), since the
respective version of the meta-model is serialized into these files.
The required steps are:

1. Download and start the jwt-view application. It will load the current
ecore file from the jwt-we project in the same project dir
2. Unmark the checkboxes of the elements/properties which should be
invisible (it may be necessary to resize the part of the application
to make sure the list of elements is displayed)
3. set the corresponding internal name using the menu ("Business" /
4. save the view to business.view or technical.view
5. repeat the steps for the second view

I hope this will help you in accomplishing your addition to the JWT meta
model. Please don't hesitate to ask if the description was unclear.

Concerning the alterations of the meta model itself:
I'm very sorry, I didn't yet respond to your suggestions. I'll read up on
the proposals and will get back to you asap.


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Montag, 19. Mai 2008 17:03
An: 'Florian Lautenbacher'; csaad@xxxxxxx
Betreff: Re: JWT metamodel extension spec

Hi Christian, Florian

I'd like to know
* how to make visible dynamic and static additions to the WEMetaModel.ecore in the Outline and in the property view. I've found the Outline class, I've generated the model and edit and it works well including saving, but nothing is displayed...
   * Chris, how what I say pans out with your ideas about JWT metamodel .


Marc Dutoo a écrit :
Hi all

I've written about JWT metamodel extension specifications at the bottom of , mainly on * "goals" : summarize all JWT members' goal for such extensions. Obviously everyone's welcome for giving some feedback ! * "design" : summarize my latest tries at hacking the JWT WE metamodel and writing sample extensions. I've still to upload the actual stuff as a bugzilla.

To make it short, for now what I like is an "aspects" relation on ModelElement (or at least Action) to an "Aspect" dynamic interface, and dynamic EMF extensions. I've also tried simple properties.

Feedback welcome !


jwt-dev mailing list

Back to the top