Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [jwt-dev] Extending the JWT Editor with Extension Points? 


5. Developing a dynamic EMF metamodel extension mechanism
I'm currently testing mixing static (java generated from genmodel) with dynamic EMF.
* sorry, I confused ecore (EMF metamodel) and XSD (XML "metamodel") in previous mails. It is possible to generate an ecore from and XSD, and from there we're in EMF world. So using XSD or EMF to define the extension is up to the extension writer. 


5.1 More about schemaLocation :
* (according to said article) EMF extended model will load ok from XML if extension ecore is present as xsi:schemaLocation in header . * However, I'm currently testing that, and it seems I still need to explicitly add the extension metamodel (.ecore file, deserialized as EcorePackage instance) explicitly in the EMF registry 
  * - but by providing ecores through extension point it would still be ok
5.2 In my tests, I still have model-based problems mixing dynamic and static EMF : * for instance, java forbids to add a dynamic model object "LogAction" that inherits from "Action" (deserialized as DynamicEObjectImpl) to a static "Activity" model Object (that is implemented by ActivityImpl), because ActivityImpl manages its subnodes in a List<ActivityNode> - and obviously DynamicEObjectImpl is not a ActivityNode in java... * A solution would be to add an ExtensibleAction model object that would have one (or more ?) untyped subnode. In this case, it would be very close to Ralph's embedded XML extension idea - actually, if we define the extension using XSD to ecore, it would even be the same. Ralph, what do you think about it ? * Limitation : that would limit the extensibility of the model, since extensible objects would have to be explicitly defined (and generated using EMF genmodel to java) beforehand * However it is rather good practice to precisely define where the metamodel might be extended... Though where should it be extensible ? (See below)
It should even be possible to automatically and dynamically generate EMF java code for custom defined EMF extension types using JET, compile and load it in the VM 


6. Which elements of the model should be extensible ?
This question is important
  * a. to help extension developers to focus at the right points
* b. because it is implied by the question of which JWT feature we allow to extend, ex. UI for custom Action property pages, transformation parts for custom model...* * c. as said in 5.2 , mixing dynamic with static EMF seems to require to slightly refactor these
So which ones - Florian, you and your JWT metamodel specialists are highly welcome ! 
  * Action obviously,
  * but why not Application instead,
  * and what about ActivityNode ?
  * DataType ?
* I'm still not sure there are no "out of the box" extensible ones, maybe DataType is ? 
  * others ?


Regards,
Marc


Marc Dutoo a écrit :

(follow up to the previous one, that is below)

(Bryan, hope you find this not out of your scope)


3. New features in JWT
For the extension developer, additional functionalities to ease development of such extensions : * We should provide helpers to ease using extended dynamic types, so developers can easily 
  * around an XSD editor, as Ralph suggested : at least Howto doc,
* at best XSD editor integrated in JWT preferences management UI, and why not in JWT packaging tooling (that would be a new component) allowing to easily package JWT for a given domain specific need 

For the user, helping graphically manage type extensions
* UI for managing allowed type extensions for a given workflow, by choosing XSDs * what about having also default known extensions, to be managed in JWT general preferences management UI ? Would it be useful ? 


4. Extension points (thanks Ralph ;)

So there could be the following extension points :
* org.eclipse.jwt.metamodel.dynamicTypes where could be hooked dynamic EMF XSDs or / and ecores. * NB. we have to see that this is consistent with the namespaces and their location written in the header of JWT workflow XML files. * org.eclipse.jwt.we.customPages where could be hooked additional custom property pages and the EMF type they activate on. * There will also be a default one that will only bring an XML editor - or even better, the EMF reflective editor ! * alternative : have an extension point per extensible JWT type, ex. one for ExtensibleAction, one for ExtensibleActivityNode... 
  * others, for other parts of JWT :
     * why not for other UI elements,
* transformation customization (though I'd like to ease as much as possible simply transferring yb recopy extended types and properties to transformed processes) 
     * ...

Regards
Marc

Marc Dutoo a écrit :
Ralph, Florian, it seems things have been moving forward on your side, that's great.
Ralph, your idea of using Eclipse plugins to extend the JWT workflow metamodel is a good one and very "eclipse-like", I like it ! (See next mail) 


Florian, I was thinking about that :


1. Dynamic EMF
Thank to your tipping me with the "dynamic emf" keyword, I found the following : http://www.ibm.com/developerworks/library/os-eclipse-dynamicemf/ . * "particularly interesting in scenarios where part of the application model code is generated through the EMF code generator, and the rest of the model code is built using Dynamic EMF" :) * basically, it uses EMF through its reflection API, and not databound generated classes. This (I think) makes it not ideal for extending the JWT graph editor, though it is perfect to store and retrieve typed extensions (properties...) in a unified manner. * NB. I believe the type extension can be loaded from an EMF XSD and therefore doesn't require to be coded in java. 

So it would be possible
* on one side for JWT developers to do "full", development-heavy extensions that extend the core metamodel and require code generation, * and on the other side to extend JWT in a costless manner ex. by creating domain-specific tasks using only an EMF XSD describing the typed extensions (we could even provide simple samples) and a property page UI. 


2. The hard part of dynamic EMF : knowing the extension XSDs
In the XML version of an EMF model, type extensions are written down as XSD schemaLocation. So the hardest part (besides actually using the extended model through the slightly cumbersome - compared to databound classes - EMF reflection API) is to provide a nice enough way to find and manage them. Here are a few ideas : * by default, trying to find the type using the schemaLocation XML header, as an absolute path or relative to the same directory as the workflow XML (or if schemaLocation is not enough, maybe define a workflow property ?) * else in a well defined "extensionRepository" directory of this JWT installation * that's another subject, but, what about defining another workflow file type : a zip file containing one workflow process file and extension type files ? 


More in next mail

Regards,
Marc

Florian Lautenbacher a écrit :

Hi Ralph,
yes, we had a very lively discussion on Thursday about the different aspects of workflow models and workflow engines. Thanks again for the warm welcome, Ralph! I agree with you that we should include a mechanism for any vendor to include their specific information in the workflow model. This could be the hooks of Bonita in XPDL, the JEE server data, etc. Probably that's also one 
of the things Bryan and Marc are discussing in another thread. So the
generic properties we are currently implementing could be a first step.
What you suggest "use Eclipse extension points to extend the model" reminds me of a presentation I heard at this year's EclipseCon, where the concept of "Dynamic EMF" was described (I believe in the context of a tool named Skyway Perspectives). I'm not familiar with that right now and will have to read 
some more, but maybe anybody else reading this mail knows about this
technique?
Anyway I'm looking more into the way the IX Workflow API and Modeler work in 
order to get a better understanding how we could bring both together.

Best regards,

Florian


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im 
Auftrag von Ralph Soika
Gesendet: 18 April 2008 11:27
An: Java Workflow Toolbox
Betreff: [jwt-dev] Extending the JWT Editor with Extension Points?

Hi,
I want to make a suggestion of how to extend the JWT Modeler with vendor 
specific extensions.
We talk yesterday to Florian Lautenbacher and Bernhard Bauer and discuss the 
possibility that we from Imixs use the JWT Editor in future to model
Workflow Models for our "Imixs IX JEE Workflow Engine".
The general requirement for us is that we need to model a lot of individual Informations/Attributes to each Activity inside the model. For example our engine supports a "IX Mail Module" which needs informations to generate a email during a transition. So now what I want to suggest is: Why not to use the concept of Eclipse 
extension points to extend the JWT Model itself?
My idea is that a vendor should not only be able to use a predefined
extension point inside the JWT Editor to add additional property pages to an 
activity object. But also a vendor can describe an individual model
extensions using the same mechanism as used by eclipse to extend a plugin. 
So for example, if we form Imixs like to extend the JWT Editor with an
additional property tab to describe the informations for our "IX Mail
Module" we also add an XSD File to describe the structure of the data. The XSD File can be very similar to the XSD Files generated with the Eclipse Plugin IDE. In fact JWT can use the existing Eclipse XSD Editor concept for 
this.
In the end the JWT Editor extends the model xml file itself with the
additional structure for an activity as described in this XSD File or
creates an additional separate Model File. The informations are provided by a property page from vendor specific plugin. Later on the IX Workflow Engine 
can parse the JWT Model file for specific extensions like the "IX Mail
Extension".
Another aspect of this concept is hat a user of the JWT Editor can switch on and off the extensions during modeling. So I can see and model using the Imixs extensions and in the next moment I switch off this extension and can see the natural model. Than I can switch on a extension from another vendor to see other aspects of the same model. This could be also a way to implement real round-trip-modelling. 

What did you think about this?

best regards
ralph




_______________________________________________
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

Back to the top