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

The Action extension point is great news !

Please tell me, what is the spec of the model extension for action ?
If there is none, I've been doing tests around Dynamic EMF since yesterday and I'd gladly contribute one, including XSD to ecore etc.
Otherwise, thanks for your "JWT metamodel expert" insight into which model elements should be extensible.
Besides that, my tests confirm that it is required to add an ExtensibleAction model object to the genmodel and static EMF, because using directly dynamic EMF extending Action would forbid to use static inner elements like Points in said dynamic Action. 

Regards,
Marc

Florian Lautenbacher a écrit :

Hi Marc, hi Ralph, hi all,

it took some time to go through all the mails you exchanged the last two
days and I hope I don't miss anything important ;-)

Yes, it seems that an dynamic extension of the metamodel would be perfect.
So we might integrate some classes into the metamodel which allow for an
extension afterwards. I had a look at another tool (the one I mentioned in a
mail earlier) and there it is the same: they have some defined extensions in
the metamodel of the core product and extend these in other plugins lateron.
So this would be kind of Dynamic EMF, but I'm not sure whether it is 100%
the idea described with Dynamic EMF.
I guess that would be a good approach: start with first classes (concepts in
the metamodel) which are as generic as possible and which then serve as
extension points for other plugins.
Additionally we need some other extension points: custom property pages and
pages for the editor itself which store the information about needed server,
etc.

The extension points: I guess at least the action and the activity would be
extension points. Everybody should have the possibility to add additional
data and information about the whole process (which would be the Activity in
JWT) or a process step (jwt:Action). Probably that's not enough, so an
JWT:Application should be extensible as well as JWT:Data or JWT:DataType. In
JWT an Application stores the information about which Java class shall be
executed, which web service shall be invoked, etc. So it's a natural
candidate for an extension. I'm not sure how often additional model elements
will appear. So it might be necessary to add an extension point for
ActivityNodes, but this one will be quite hard. However, if somebody would
like to explicitely model StateNodes (e.g. needed in Imixs and for jPDL I
guess), then such an extension point might be helpful, too. But I guess for
the beginning we should really concentrate on the most important ones.
The extension point for Actions is currently implemented and will be
finished in a few weeks I hope, the one for Activities is also already a bug
in Bugzilla and will probably be considered next. The other ones will
probably follow...
Concerning new features in JWT: -supporting the user to create dynamic types, extensions of existing 
actions, etc. either through wizards or at least with enough tutorials and
how-to's as possible
-packaging of JWT for specific needs: would that include the creation of
views of the process model as well as integration of other plugins for
example for additional property tabs, server information, code generation or
transformation, etc.? Yes, indeed a very good idea. Those packages should
then be available in the download area of JWT I guess?


Best regards,

Florian


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Ralph Soika/IMIXS
Gesendet: 22 April 2008 12:21
An: Java Workflow Toolbox
Betreff: Re: AW: [jwt-dev] Extending the JWT Editor with Extension Points?

Hi Marc,

yes I agree with you in the point of the idea with ExtensibleAction model
object:
* 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. 
And I agree also to you to allow more then one untyped subnodes. As
different vendors can support different extensions for one Action or
ActivityNode.
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 ?


In this question I would propose Action and also ActivityNode.
What did you mean with "Application". An extension mechanism for application
specific or workflow engine specific data would be helpfull in some cases.
So the Imixs IX Modeler holds informations like the WebService Endpoint from
the Engine. This is configuration stuff. But why not allow a vendor to
extend such data.
If you take a look at following picture you can understand what I mean:
http://www.imixs.org/websites/imixs-org.nsf/vResourcesNameLookup/WorkflowMod
eler.ScreenShots/$FILE/image_small_01.gif

The main editor is implemented as a multipage editor and a Vendor can extend
the editor with an additional pages (like the JBoss page in the picture).
This page holds application or engine specific data.

Is this compatible with your approach Marc?

best regards
Ralph

Back to the top