[
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.
Regards,
Marc
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,
Florian
-----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
Points?
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.
Bryan
_______________________________________________
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
