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, Bryan

I think we should not use the JWT model to show things that are too remote from it. That's why there are transformations ex. with BPMN that has its own editor in STP.

Though customizing the view (ex. icons) thanks to extended model data is a very good idea.

More about mixing model and view :
* I've read in an eclipsecon presentation that, though mixing model and view is not good in theory, in EMF you usually end up this way and it works "well". * the STP BPMN editor, using GMF diagram technology, justly separates its model in a .bpmn file and visual information in a .bpmn_diagram file. * improving JWT : typically, Location, Size etc. elements could be not subelements of ex. Actions, but in another place and referring the Actions they pertain to.


Florian Lautenbacher a écrit :
Hi Bryan,

thanks for your question which raises an interesting point we should think
of. Actually, we are using EMF and GEF, but not GMF as we would like to in
the future. So, we only got one meta-model: to describe the concepts that
are needed for the workflow. The graphical representation is at the moment
hard-coded, so it is also only possible to have one graphical representation
for the workflow model. In bug 225706 I described the idea of using the
underlying metamodel to show different graphical representations. Maybe an
own metamodel would be useful, here, too, but for the moment we don't have
the resources to implement that. Maybe in the near future...
So the discussion with extension points is not about the graphical
presentation, but about how process engine specific data (e.g. for MWE,
Imixs, jBPM, Bonita, etc.) could be integrated into the model WITHOUT
changing the graphical display simply by adding some properties and
additional pages to insert these properties.
I hope that makes it a little bit clearer.

Best regards,


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Bryan Hunt
Gesendet: 23 April 2008 03:15
An: Java Workflow Toolbox
Betreff: Re: AW: AW: [jwt-dev] Extending the JWT Editor with Extension

I've been trying to follow all of the recent emails on the topic, but I
think I might be a bit lost.  It's not exactly clear what you are extending
in the discussions.  From my point of view, there should be two meta-models:
one that you use to describe a workflow, and one that describes the
graphical representation of that workflow.  Does this view fit into this
discussion on extension points?

On Apr 22, 2008, at 10:57 AM, Florian Lautenbacher wrote:

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.

Does this comment refer to the work I'm doing, or something different?

BTW, I'm not a workflow expert, so I apologize if you have to repeat
yourself as I attempt to become educated on this topic.  I'm very interested
in this topic from a simplistic engineering point of view as a tool for
solving a class of similar problems.

jwt-dev mailing list

jwt-dev mailing list

Back to the top