[
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?
|
Hi Ralph, all
Yeah, I forgot to say that we should, stay as simple as possible ^^
My first concern is to have as nice as possible XML in workflow files :
it'd pain me to have XML in CDATA below Actions element...
Since we're using EMF to produce this XML, I'm having a deep look at
this technology, though other are neither out of the question nor
incompatible, ex. see what I said in my previous mail about XSD).
Now more about your mail :
* 1. "the other reason why I would not view extensions in the
graphical editor, is that the model will become more and more unclear.
We tried this a lot" -> thanks for the feedback. I agree that graphical
representation of extensions is not a priority but rather a pitfall. OK
for the idea of UI pages, like PropertyView.
* 2. having "multiple files", ex. a core worfklow file and a "log"
extension file : managing consistency of multiple files (ex. having a
LogAction specify where it hooks up in the core file) may prove hard
(not only for displaying it, but also for transforming it to executable
processes...). I'd prefer extended information to appear where it
applies, for the sake of simplicity also. So I'm not fond of this
(though two files would be better than a single one with CDATAs !).
* But I agree with all other ideas, especially the behaviour of
the extension point. Even using EMF as model extension technology, we
could provide helpers so the extension plugin writer can have access at
a model object's extension information as EMF or XML (simple matter of
EMF fragment <-> XML conversion) or why not even Java generated from EMF
genmodel.
& you do not confuse me ^^
Regards
Marc
Ralph Soika/IMIXS a écrit :
Hi Marc,
thanks for your informations. I agree with you that the integration
of schema extensions can become really hard. I have no idea how this
can be done with EMF / dynamic EMF .
I want to point out two things which could make it easier.
1.) no graphical representation in the JWT Editor of extensions!
- it could be very hard to analyze the objects of an extension and
view them in the graphical representation of the model.
- the other reason why I would not view extensions in the
graphical editor, is that the model will become more and more unclear.
We tried this a lot of times at Imixs. And in the end the model was no
more useful. I think the main goal of the graphical editor is to give
a user a fast way to navigate throw the process. Not to show any
aspect of technical details of a model. These technical details should
be viewed by PropertyPages.
So this is the reason why I would not expect a graphical
representation of extensions and I would not advise to do so.
So the vendor how wants to extend the model should not expect that the
jwt-editor shows a lot of gaudy pictures. But the vendor which is
extending the model by a Eclipse-Plugin should implement a
PropertyView which is able to view all necessary informations of this
extension. Maybe he can add an additional graphical editor which is
representing the model including extensions of the vendor. But the
main model from JWT Editor should still be clear and easy to understand.
2.) why not to store model informations in multiple files?!
I don't think that it isn't "eclipse like" to store complex model
informations in multiple files. So if I use different extensions
(Plugins) in my JWT Modeler the modeler can store this in multiple
files. The filename (eclipse file resource) can be created by the JWT
Main Modeler Plugin. So a vendor have to use this pre-gernerated file
resource object. So the control of the files is by the JWT Mail
Plugin. The content of the file is controlled by the vendor of an
extension. Mybe the vendor have to write the data generated by his
propertypages and also read them out if a model object was selected in
the graphical JWT editor
So the behavior of the extension point could be very easy from the
view of the JWT Editor:
* The graphical Editor will not be changed.
* The JWT Editor informs each Plugin if an Object was selected form
the editor. So it can load the extended data.
* The JWT Editor suports a pre-generated file resource object to the
plugin according to the main model file to give the plugin the
chance to store the data.
* The Extension defines how the property page can be extended (we
have implemented this in the Imixs IX Modeler)
If you don't like the idea with multiple files than the Extension
Point can be claim a plugin to get the xml representation of the data
to a specific part of the model.
So I hope that I did not confuse you all to much now?
best regards
Ralph
Marc Dutoo schrieb:
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
