[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] Changing toolbar for BPMN
|
Hi Pierre, hi Marc,
I agree that changing the muliplicity of edges on a node needs to be
considered carefully. As Marc already said the multiplicity of an
ActivityNode is not restricted, but on Action it is. So for the moment it is
only allowed to have one incoming and one outgoing edge from an Action. This
is a basic requirement in order to specify the semantics of more than one
outgoing edge: if they should be executed in parallel threads, a ForkNode is
needed, for alternative edges a DecisionNode should be added to the model.
After this DecisionNode a Guard on the ActivityEdge is expected whereas
after an Action no Guard is expected and is currently simply neglected (if
specified) by BPEL-generation or Simulation.
Therefore, if you think you need such an element in order to model BPMN you
should define a new subnode of ExecutableNode as an Aspect just as Marc
explained and use this new kind of "Action" (it should be named
differently). Using the different views you can now say that this new
"Action" should be displayed and not the currently existing Action. But be
aware that the existing model transformations, other views, Simulations,
code generations, etc. won't be able to cope with this new "Action" at the
beginning!
I agree with Marc that we need a mechanism to allow the visibility of an
Aspect-created ChildExtender in the Palette. This will be the next ToDo
after we included the Aspect-additions from the metamodel branch in the JWT
head. I hope Chris might be able to work on this in the next weeks...
Another problem with BPMN will probably be the possibility to show Roles not
connected as ReferenceableElements (with edges to each Action), but grouping
the Actions in Swimlanes instead. We already implemented a first version a
year ago, but realized that it will be necessary to store the
GraphicalElement-details for each element for each view differently.
Currently the location, width and height of each element is only stored once
for each view. This will be a problem in the future with several views and
the usage of different icons - we already discussed that in our last
telephone conference.
So, there is still much to do :-)
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 05 September 2008 16:48
An: Java Workflow Toolbox
Betreff: Re: [jwt-dev] Changing toolbar for BPMN
Hi Pierre
I forgot something important.
If you change the basic semantics (core node types and their connection) of
the workflow model, you defeat JWT's purpose : for examplen if you give such
a semantic-specific model to another JWT-based tool, it won't be able to
work with it or even understand it.
That's why creating new node types is discouraged.
And for the same reason, changing node multiplicity must be carefully
considered as well : for example, allowing many outputs from an Action node
is actually the same as an Action node followed by a Fork node with as many
outputs ; and other tools (or plugins, like workflow export
plugins) expecting such a Fork node surely won't expect many outputs from an
Action node.
There are many ways to obtain either a "pure" BPMN editor, out of JWT,
including customizable input and output node connections, new node types,
but also displaying the two nodes (Action and Fork) on top of each other, or
deciding to support a "non pure" version of BPMN but still letting the user
add two nodes in a single Palette drag and drop (with a configurable
Palette).
So we should discuss and agree on how this case should be handled in JWT, so
other JWT based tools or plugins will be aware of it ! Everyone else, your
input is welcome.
Regards,
Marc
Marc Dutoo a écrit :
> Hi Pierre
>
> Indeed, jwt-we is the place to start !
>
> Here is some starting information that should be useful for a vendor,
> so you can build your own tool on JWT. It should really go to the wiki
> ;)
>
> JWT is basically
> * UI : a GEF diagram editor
> * UI : as well as an Outline and Property View editor provided by
> EMF.edit (EMF's edition framework)
> * model : built on top of an EMF model, meaning EMF is quite central
> to JWT
> * the whole being an eclipse plugin, meaning it can benefit of other
> plugins, and can be extended along defined extension points (see
> plugin.xml 's extension point tab).
>
> About JWT's EMF :
> * EMF's conf is at
> jwt-we/src/org/eclipse/jwt/we/model/WEMetaModel.ecore
> * EMF.edit is configurable in
> jwt-we/src/org/eclipse/jwt/we/model/WEMetaModel.genmodel
> * EMF and EMF.edit generated classes are in
> src/org/eclipse/jwt/model , so don't code too much there ;)
>
>
> How to extend JWT :
>
> As an entry point, see http://wiki.eclipse.org/JWT_Extensions (to be
> completed). It talks about (External) Actions, Views and Property
> Sheet tabs.
>
>
> 1. Adding information in the workflow model :
>
> To add specific technical or business information on workflow nodes,
> define and use your own aspects, or use their simplest form :
> DynamicProperty .
> [uses specific workflow configuration editable in the outline,
> advanced uses require plugin definition and EMF definition, possibly
> EMF java coding]
>
> They are editable in the Outline and the Property View. Custom UI also
> can be developed and made available in the node's Property View.
> [requires plugin definition and SWT UI java coding]
>
> See features at https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567
> and (older) http://wiki.eclipse.org/JWT_Metamodel .
>
> Note : still in branch, being merged in the trunk.
>
>
> 1.bis Creating new node types :
>
> DISCLAIMER : We STRONGLY discourage creating new node types, because
> we think it is important to standardize on a small, meaningful set of
> nodes, and rather add specific properties or features using aspects.
>
> You could create additional new workflow node types either in another
> EMF metamodel using EMF child extenders, or changing the core JWT EMF
> metamodel (which is BAD PRACTICE).
> [requires plugin definition and EMF definition, possibly EMF java
> coding]]
>
>
> 2. Changing which nodes are displayed and how :
>
> To change which nodes are displayed and how, define and use your own
> JWT View, using the JWT View file swing editor (available in the
> we/jwt-view project). [uses specific file configuration]
>
> To change icons and figures using views, I guess you've already looked
> how it works at https://bugs.eclipse.org/bugs/show_bug.cgi?id=238259 ,
> where you can find a sample UML view with custom figures (thanks to
> Florian). [requires plugin definition and java coding]
>
>
> 3. Enriching your model's behaviour using EMF :
>
> EMF allows you to enrich existing behaviour of your model, by being an
> Adapter (and INotifyListener) and hooking up on model events. For
> example, in the METAMODELEXT branch, when an element is created, the
> AspectEventManager automatically creates subelements (aspects)
> according to its configuration :
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jwt/we/jwt-we/src/org/e
clipse/jwt/we/modelext/aspects/AspectEventManager.java?revision=1.1.2.1&root
=Technology_Project&view=markup&pathrev=BRANCH_METAMODELEXT_20080710
>
>
> And listening to those events is as simple as adding your Adapter to
> the root ItemProvider AdapterFactory, as described in
> WEEditor.createEmfEditingDomain() here :
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jwt/we/jwt-we/src/org/e
clipse/jwt/we/editors/WEEditor.java?revision=1.23.2.6&root=Technology_Projec
t&view=markup&pathrev=BRANCH_METAMODELEXT_20080710
>
>
> // adding aspectsEventManager
> INotifyChangedListener aspectEventAdapter =
> Aspects.getInstance().getAspectEventManager();
> composedAdapterFactory.addListener(aspectEventAdapter);
>
> Finally, even the model java code that has been generated by EMF can
> be possibly edited and reprogrammed.
>
> However, all that it is limited by
> * what your model says it can do (see its definition in
> jwt-we/src/org/eclipse/jwt/we/model/WEMetaModel.ecore with the EMF
> editor), though aspects (or even EMF child extenders) can enrich it,
> * and what the GEF editor is programmed for, though it is extensible
> (views), or can be reprogrammed, or even made more extensible.
>
> [requires java coding]
>
>
> 4. Adding UI actions in the toolbar :
>
> To add (External) Actions in the toolbar, see
> http://wiki.eclipse.org/JWT_Extensions
> [requires plugin definition and java coding]
>
>
> 5. Others - reprogramming FAQ, or extension wishlist :
>
> 4. Changing output / input node limit
>
> Fortunately ActivityNode's model can have multiple output and inputs.
> So you just have to modify the GEF editor. In
> jwt-we/src/org.eclipse.jwt.we.parts.processes.ActionEditPart , you can
> see :
> public ActionEditPart() {
> setMaximumInActivityEdges(1);
> setMaximumOutActivityEdges(1);
> }
> So by changing the maximum set, you can let it have more connections !
> [requires java coding, could be made configurable in a plugin]
>
>
> 4.2 Adding new elements to the palette
>
> As you've found it (congratulations !), EMF model elements are added
> to the palette in the Palette class in this way :
> addPaletteDrawer(<palette group>, <EMF class>);
> So you can add your own this way.
>
> Note that this means that you must have such an EMF element to add...
> Read on :
>
> As you've understood after reading 1. and 1.bis, the best way would be
> to define an aspect and make it autocreated on an existing workflow
> node type, ex. Action. However this aspect will therefore be on ALL
> such nodes. So it is a good way to customize an existing node type
> (ex. all Actions must have the BonitaEventHookAspect), but not to
> provide a way to create a differently enriched type of node (ex. so
> there would be in the palette an Action entry, but also an Action With
> Log that uses a log aspect entry).
>
> To achieve the last one, we could make Palette "aspects-aware" and
> configurable in a plugin.
>
> For now, the only solution would be to wait for it... and try it out
> by defining a new identical type in the JWT metamodel (or as EMF child
> extender) ;)
>
> [requires EMF and java coding, could be made configurable in a plugin]
>
>
> Regards,
> Marc
>
>
> Pierre Vigneras a écrit :
>> Dear all,
>>
>> I would like to change the toolbar of JWT in order to provide BPMN
>> icons and concepts.
>> I have some questions about where to start from (considering the big
>> number of JWT Eclipse sub-projects,
>> and their relevant packages). I suppose that the good place to start
>> with is the jwt.we package.
>>
>> There, I found the Palette class where the following code :
>>
>> addPaletteDrawer(activityGroup, ProcessesPackage.Literals.ACTION);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.INITIAL_NODE);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.FINAL_NODE);
>> addPaletteDrawer(activityGroup, EventsPackage.Literals.EVENT);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.FORK_NODE);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.JOIN_NODE);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.DECISION_NODE);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.MERGE_NODE);
>> addPaletteDrawer(activityGroup,
>> ProcessesPackage.Literals.GUARD);
>>
>> Brings me to the EMF components : ProcessesPackage.Literals
>> interface. My question is: if we want to modify not only the icon
>> (UML to BPMN) but also the behavior (for example: a node (task) can
>> have multiple incoming/outgoing edges (transitions)) how can we
>> implement that behavior? Should we use inheritance, or is there a
>> standard (EMF) way of extending (means not only adding things, but
>> also modify/speciale existing things) the JWT model?
>>
>> Thanks for your help.
>>
>>
>
> _______________________________________________
> 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
