[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] Extending the JWT Editor with Extension Points?
|
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
