[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jwt-dev] AW: JWT and orchestration / web services / databinding, Extension Points-discussion
|
Hi Marc,
I didn't intend to change the view completely, e.g. by trying to display
BPMN. But right now it is completely proprietary, but with some changes it
could easily be used as a modeling tool for UML activity diagrams. So, we
are just thinking of changing the icons that are displayed for each model
element. But this is left to future work (we are not working on this issue
right now)
Conerning the mixture of model and view: you are right that normally
location, size, etc. should not be part of the metamodel and better be
located somewhere else (e.g. in another file). But I fear this won't be easy
to implement due to backward compatibility. However, just enter it as a bug
report, if you like and we'll have a closer look.
Regarding web services: I just had another discussion with Chris Saad and he
didn't start changing something on the metamodel. The idea was this:
currently, Application contains properties such as Java class, JAR-archive,
method, etc. So any subclass of Application (such as WebServiceApplication)
would inherit these properties, too, but does not need those. So, the idea
was to have an Application without any properties and new subclasses such as
JavaApplication or WebServiceApplication. All former Applications would then
be mapped to JavaApplications and in the future one can decide whether to
specify a java program or a web service invocation. This would also be
necessary to create an extension point for future types (e.g.
CorbaApplication, XPDL, etc.). But, as already mentioned, we just discussed
this and didn't start implementing it. So, if you have any idea of
improvement, we will be happy to hear that :-)
An expression language for data mapping? Hmm, I don't know exactly how that
might work. Would you specify "here I got parameter A, B and C and A is
similar to x and B and C must be combined this-and-that-way in order to
become y"? But if you know a good language to do such a mapping: why not! I
simply don't want to invent a new one :-)
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 23 April 2008 17:50
An: Java Workflow Toolbox
Betreff: 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
>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
