[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] AW: Making new JWT metamodel elements visible in the JWT WE UI
|
Hi Marc, hi all,
thanks a lot for the detailed description of how the JWT Metamodel might be
extended. Even without the code in a bugzilla I was able to implement the
same on my computer and test the samples based on the source in the wiki.
So with your sample it is easy to have a workflow-file that is not only
based on the WEMetamodel.ecore but also on an additional .ecore which is
woven into the metamodel with aspects. However, this allows only the editing
of existing files, but not the creation of new files, am I right?
Concerning where the extensions do come from you offered three
possibilities:
1) a standard directory with all the ecores
2) a new button "add extension model" which allows the user to select an
ecore file
3) vendor-specific preconfiguration e.g. with pathes in predefined
plugin.xml.
Maybe a mixture of these three would be possible? We say there is a standard
directory which is always searched for and all ecore-files in there are
automatically loaded. This can also be used by vendors already (considers 1)
and 3)) and additionally we may provide a button to select another directory
(2)) to load the .ecore-files there, too. What do you think about that?
So we need to adapt the WE in order to enable a user not only the creation
of elements in the WEMetamodel.ecore, but also to create elements which are
defined in one of the other ecores... But this will be quite difficult I
guess.
I also agree that versioning of the ecore-files is quite important in order
to have the possibility to change the metamodel slightly afterwards and
still be able to read existing files. This is somehow similar to the already
existing WEConverter, but with the new and prior unknown .ecore-files
probably quite hard to implement.
Concerning the JWT Views and your suggestions: I will try to find a student
making a bachelor thesis who can change the UI from Swing to SWT, add the
possibility to choose several ecores and create the basis of a
jwt-release-builder. I hope I'll find somebody soon - alas, that is not very
easy. The student who should work on the action extension point quit
yesterday having implemented nothing useful for us :-( Hopefully I'll soon
find somebody else...
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 27 May 2008 23:07
An: Java Workflow Toolbox
Betreff: Re: [jwt-dev] AW: Making new JWT metamodel elements visible in
theJWT WE UI
Hi
Please find some improvements and additions (marked "added 20080527") at
http://wiki.eclipse.org/JWT_Metamodel , 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.
Christian,
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.
Regards,
Marc
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 standard.
>
> 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.
>
> Regards,
> Chris
>
>
> -----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 !
>
> Regards,
> Marc
>
> Christian Saad a écrit :
>
>> Hi Marc,
>>
>> the visibility of the model elements is controlled by the JWT views
>>
> concept.
>
>> 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
>>
> files
>
>> 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
>>
> window
>
>> to make sure the list of elements is displayed) 3. set the
>> corresponding internal name using the menu ("Business" /
>> "Technical")
>> 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.
>>
>> Regards,
>> Chris
>>
>>
>> -----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 .
>>
>> Regards,
>> Marc
>>
>>
>> Marc Dutoo a écrit :
>>
>>
>>> Hi all
>>>
>>> I've written about JWT metamodel extension specifications at the
>>> bottom of http://wiki.eclipse.org/index.php?title=JWT_Metamodel ,
>>> 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 !
>>>
>>> Regards,
>>> Marc
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> 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
