Home » Archived » Service Oriented Architecture Tools Platform (STP) » Re: Extending STP BPMN
| Re: Extending STP BPMN [message #374562] |
Fri, 08 February 2008 12:34  |
 Roland Gude
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi,
I have been trying to customize The BPMN modeler for my needs, too.
I have noticed that other try to do similar customizations. Therefor i
wanted to provide what i found out here.
One of the possibilities i tryed is not completely usable however, because
it
requires that extensions have Ids. This is not the case for the extensions
of org.eclipse.stp.bpmn.diagram plugin. It would be nice if some Ids would
be added.
Customization steps:
1) write a new Plugin
2) customizing the palette
possibility a) Create a new Extension in your plugin.xml,
which defines a new Editor. Use the BpmnDiagramEditor
as the class (exactly like the original editor
extension) but use a different ID (like
my.customized.Editor)
Overwrite BpmnPaletteFactory and BpmnPaletteProvider.
In BpmnPaletteProvider simply overwrite the
contributeToPalette Method and let it use your newly
created PaletteFactory.
public class MyPaletteProvider extends BpmnPaletteProvider implements
IPaletteProvider {
public void contributeToPalette(IEditorPart editor, Object content,
PaletteRoot root, Map predefinedEntries) {
BpmnPaletteFactory factory = new MyPaletteFactory();
factory.fillPalette(root);
}
}
public class WFPaletteFactory extends BpmnPaletteFactory {
public void fillPalette(PaletteRoot paletteRoot) {
PaletteEntry pe = null;
for (Object paletteEntry : paletteRoot.getChildren()) {
pe = (PaletteEntry)paletteEntry;
if (pe.getId().equals(PaletteService.GROUP_STANDARD)) {
break;
}
pe = null;
}
if (pe != null) {
setupStandardPaletteEntries(pe);
}
/*
*
* Add your contributions
*
*/
ToolEntry toolEntry = paletteRoot.getDefaultEntry();
SelectionToolEx.setToolClass(toolEntry, SelectionToolEx.class);
}
}
This second codeblock could be simplified if
BpmnPalettefactory would use a method addItems() in its
fillPalette() method. his would reduce code duplication.
After you have created thos classes, add another
extension
to your plugin.xml:
[code]
<extension
point="org.eclipse.gmf.runtime.diagram.ui.paletteProviders" >
<paletteProvider
class="my.package.MyPaletteProvider">
<Priority
name="Highest">
</Priority>
<editor
id="my.ID">
</editor>
</paletteProvider>
</extension>
[code]
where my.ID is the Id you previously used for your new
editor.
possibility b)
This Possibility is a little easier in principle, but not
fully possible with the current BpmnModeler, because The
extensions in bpmn.diagram plugin have no Ids. This
could
however be fixed without much effort (they should have
ids
anyways)
supress the extensions which provide to the palette by
associating them with a disabled activity.
to do that, put this in your plugin.xml
<extension
point="org.eclipse.ui.activities">
<activity
id="A.Never.Used.Id"
name="Hidden activities"/>
<activityPatternBinding
activityId="A.Never.Used.Id"
pattern="org.eclipse.stp.bpmn.diagram/.*"/>
</extension>
notice that this exact line will disable all extensions
in
bpmn.diagram plugin (due to the .* pattern).
If the extensions would have an Id, you could substitute
the
.* with the Id of the provider you want to disable.
2) Customizing the ModelingAssistant:
supress the modellingAssistant from bpmn.diagram like shown in 1b
write your own modelingAssistant.
create an extension in your plugin.xml
<extension
point="org.eclipse.gmf.runtime.emf.ui.modelingAssistantProviders">
<modelingAssistantProvider
class="de.dlr.rcenvironment.workflow.WFModelingAssistantProvider">
<Priority
name="lowest">
</Priority>
<editor id="my.Id">
</editor>
</modelingAssistantProvider>
</extension>
where my.Id is the Id of Editor you chose in 1a) or if you did not
create
your own editor but still use the original BpmnEditor:
"org.eclipse.stp.bpmn.diagram.part.BpmnDiagramEditorID"
I hope this helps.
And one question for the Bpmn Developers:
could you give Ids to your extensions, so that it would be possible to
disable
providers which do add to many items?
kind regards,
Roland Gude
|
|
|
| Re: Extending STP BPMN [message #374563 is a reply to message #374562] |
Sat, 09 February 2008 07:12  |
Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Hi Roland,
first, we plan on writing a complete tutorial that we will present at
EclipseCon on the best ways to extend the modeler. We will make all
materials available.
Roland, regarding your problem with providers and your idea of using
extension points in general, I would like to bring your attention to
this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=111221
It demonstrates that using extension points is not the best way to
scale. We prefer to use Java to add or remove elements because it is
easier to tweak.
Please feel free to open an enhancement request to help extend the
modeler and give us a patch, we will look at it.
I hope this helps.
Antoine
Roland Gude wrote:
> Hi,
>
> I have been trying to customize The BPMN modeler for my needs, too.
> I have noticed that other try to do similar customizations. Therefor i
> wanted to provide what i found out here.
>
> One of the possibilities i tryed is not completely usable however,
> because it
> requires that extensions have Ids. This is not the case for the extensions
> of org.eclipse.stp.bpmn.diagram plugin. It would be nice if some Ids
> would be added.
>
> Customization steps:
> 1) write a new Plugin
>
> 2) customizing the palette
> possibility a) Create a new Extension in your plugin.xml,
> which defines a new Editor. Use the BpmnDiagramEditor
> as the class (exactly like the original editor
> extension) but use a different ID (like
> my.customized.Editor)
>
> Overwrite BpmnPaletteFactory and BpmnPaletteProvider.
> In BpmnPaletteProvider simply overwrite the
> contributeToPalette Method and let it use your newly
> created PaletteFactory.
>
>
> public class MyPaletteProvider extends BpmnPaletteProvider implements
> IPaletteProvider {
>
> public void contributeToPalette(IEditorPart editor, Object content,
> PaletteRoot root, Map predefinedEntries) {
> BpmnPaletteFactory factory = new MyPaletteFactory();
> factory.fillPalette(root);
> }
> }
>
>
>
> public class WFPaletteFactory extends BpmnPaletteFactory {
>
> public void fillPalette(PaletteRoot paletteRoot) {
> PaletteEntry pe = null;
> for (Object paletteEntry : paletteRoot.getChildren()) {
> pe = (PaletteEntry)paletteEntry;
> if (pe.getId().equals(PaletteService.GROUP_STANDARD)) {
> break;
> }
> pe = null;
> }
> if (pe != null) {
> setupStandardPaletteEntries(pe);
> }
> /*
> * * Add your contributions
> * */
>
> ToolEntry toolEntry = paletteRoot.getDefaultEntry();
> SelectionToolEx.setToolClass(toolEntry, SelectionToolEx.class);
> }
> }
>
>
> This second codeblock could be simplified if
> BpmnPalettefactory would use a method addItems() in its
> fillPalette() method. his would reduce code duplication.
>
> After you have created thos classes, add another extension
> to your plugin.xml:
> [code] <extension
> point="org.eclipse.gmf.runtime.diagram.ui.paletteProviders" >
> <paletteProvider
> class="my.package.MyPaletteProvider">
> <Priority
> name="Highest">
> </Priority>
> <editor
> id="my.ID">
> </editor>
> </paletteProvider>
> </extension>
> [code]
>
> where my.ID is the Id you previously used for your new
> editor.
>
>
>
> possibility b)
> This Possibility is a little easier in principle, but not
> fully possible with the current BpmnModeler, because The
> extensions in bpmn.diagram plugin have no Ids. This
> could however be fixed without much effort (they should
> have ids anyways)
>
> supress the extensions which provide to the palette by
> associating them with a disabled activity.
>
> to do that, put this in your plugin.xml
>
>
> <extension
> point="org.eclipse.ui.activities">
> <activity
> id="A.Never.Used.Id"
> name="Hidden activities"/>
> <activityPatternBinding
> activityId="A.Never.Used.Id"
> pattern="org.eclipse.stp.bpmn.diagram/.*"/>
> </extension>
>
> notice that this exact line will disable all extensions in
> bpmn.diagram plugin (due to the .* pattern).
>
> If the extensions would have an Id, you could
> substitute the .* with the Id of the provider you want
> to disable.
>
> 2) Customizing the ModelingAssistant:
> supress the modellingAssistant from bpmn.diagram like shown in 1b
>
> write your own modelingAssistant.
>
> create an extension in your plugin.xml
>
> <extension
> point="org.eclipse.gmf.runtime.emf.ui.modelingAssistantProviders">
> <modelingAssistantProvider
>
> class="de.dlr.rcenvironment.workflow.WFModelingAssistantProvider">
> <Priority
> name="lowest">
> </Priority>
> <editor id="my.Id">
> </editor>
> </modelingAssistantProvider>
> </extension>
>
>
> where my.Id is the Id of Editor you chose in 1a) or if you did not
> create your own editor but still use the original BpmnEditor:
> "org.eclipse.stp.bpmn.diagram.part.BpmnDiagramEditorID"
>
>
> I hope this helps.
>
> And one question for the Bpmn Developers:
> could you give Ids to your extensions, so that it would be possible to
> disable
> providers which do add to many items?
>
> kind regards,
> Roland Gude
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
|
| Re: Extending STP BPMN [message #374564 is a reply to message #374563] |
Mon, 11 February 2008 12:10 |
Roland Gude
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi,
i would favour a Java-only solution to my problems as well (I have to
write some Contributers anyways). Unfortunately i was unable to find one
until now.
The solution for the palette is pretty straight forward (overwriting the
provider, defining new editor, associating provider and editor via
plugin.xml), but it does involve a fair load of plugin.xml stuff anyway
(Or am I missing a possibility to tell the original BPMN Modeler to use
another PaletteFactory/PaletteProvider?).
Disabling the modelingAssistant popup seems to be more difficult because
an extension which adds to that extensionpoint does not seem to specify
for which eitor its contributions are meant. Instead it seems to figure
out what fits where in some Java code (which i am currently unable to find
-- correct me if i am wrong).
This means that if i write a new provider which adds some things to the
modelassistant, they are available to all editors. Therefor my customized
editor ends up with all contributions from the BPMN modeler and my
customized contribution (while i wanted to remove those from the BPMN
modeler, or at least some of them.) That is why i turned off the
modelingAssistant from bpmn.diagram (and turning of that one allone is not
possible right now due to the missing extension Ids).
If there is a Java only solution which allows me to
remove/add some contributions from/to the palette/modelAssistant
I am eager to hear it.
What is your time schedule for releasing the tutorial (can i get my hands
on it prior to eclipsecon? i know it is a lame excuse, but i need the
customized editor within a couple of weeks). If i can help with that
customization guide in any way, don't hesitate to ask. For the next two or
three weeks i will be working more or less full time on that topic anyway.
kind regards,
roland
Enhancement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=218489
a plugin.xml with Extension IDs is aattached
|
|
|
| Re: Extending STP BPMN [message #374565 is a reply to message #374564] |
Mon, 11 February 2008 13:20 |
| Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Roland Gude wrote:
> Hi,
>
> i would favour a Java-only solution to my problems as well (I have to
> write some Contributers anyways). Unfortunately i was unable to find one
> until now.
>
> The solution for the palette is pretty straight forward (overwriting the
> provider, defining new editor, associating provider and editor via
> plugin.xml), but it does involve a fair load of plugin.xml stuff anyway
> (Or am I missing a possibility to tell the original BPMN Modeler to use
> another PaletteFactory/PaletteProvider?).
I think that's good enough. At that point if you want your own palette,
you probably want your own modeling assistant, so you'll have to
subclass the editor no matter what. More below.
>
> Disabling the modelingAssistant popup seems to be more difficult because
> an extension which adds to that extensionpoint does not seem to specify
> for which eitor its contributions are meant. Instead it seems to figure
> out what fits where in some Java code (which i am currently unable to
> find -- correct me if i am wrong).
> This means that if i write a new provider which adds some things to the
> modelassistant, they are available to all editors. Therefor my
> customized editor ends up with all contributions from the BPMN modeler
> and my customized contribution (while i wanted to remove those from the
> BPMN modeler, or at least some of them.) That is why i turned off the
> modelingAssistant from bpmn.diagram (and turning of that one allone is
> not possible right now due to the missing extension Ids).
Please see the GMF bug I mentioned earlier. The provider and service
concepts are evil. All providers are executed with a strategy FORWARD,
so you can't do anything about them.
>
> If there is a Java only solution which allows me to
> remove/add some contributions from/to the palette/modelAssistant
> I am eager to hear it.
Yes, we bumped into the same problem, so we tried to stay clean from
plugin.xml madness:
You can remove elements from the modeling assistant by overriding the
editing domain and add the elements to filter.
BpmnDiagramEditDomain#setRemovedElementTypes(Set<IElementType > elementTypes)
You can override the createDiagramEditDomain() method of the
BpmnDiagramEditor subclass, and add the element types to filter there.
>
> What is your time schedule for releasing the tutorial (can i get my
> hands on it prior to eclipsecon? i know it is a lame excuse, but i need
> the customized editor within a couple of weeks).
The time schedule is EclipseCon. But we plan to work using the wiki.
If i can help with that
> customization guide in any way, don't hesitate to ask.
Please help us with that. I can create a first page, give you some kind
of outline. I'll start working on that full time soon.
For the next two
> or three weeks i will be working more or less full time on that topic
> anyway.
>
> kind regards,
> roland
>
> Enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=218489
This enhancement request is too vague to help. I assigned it to me and
commented.
>
> a plugin.xml with Extension IDs is aattached
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
| |
| Re: Extending STP BPMN [message #374568 is a reply to message #374567] |
Wed, 20 February 2008 13:12 |
Roland Gude
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Now that i have worked with the extension mechanism of BPMN modeler, i
wanted to provide some thoughts and feedback.
First of all, it is really nice, that it is possible to customize the
modeler in pure Java (appart from the xml-stuff required by eclipse).
There are however some things I did not like about the extension mechanism.
Customization includes adding and removing of elements to palette and
modelingAssistant-Popup.
Adding and removing things from the palette works well and seems to work
without a problem.
Unfortunately the popup bar is a bit more complicated.
currently, if you want to remove items from the popup bar, you overwrite
Editor createDiagramEditDomain() method and provide a blacklist of
elements you do not want.
The following issues arise from that:
1)Duplication of code
The overwritten createEditDomain() method looks almost exactly like its
super version. Could easily be solved with factory pattern (selecting the
editdomain) or better Template method pattern (selecting EditDomain and
selecting Blacklist).
2) When you want to limit the elements available in your editor, you need
to know about all elements that are available. This is knowledge the
Developer will usually not have (at least if the user can install
extensions, which usually is the case). Another extension (which you do
not know of) can pollute your editor.
This is a general problem of the "blacklisting" approach. This could be
solved with a "Whitelisting" approach or better even a mix of blacklist
and whitelist.
I.e. add a method "List<IElementType> getWhitelist()" and
"List<IElementType> getBlacklist()"
Internally you would only get those elements on your whitelist, which are
not on you blacklist. If you do not want all elements your super class
whitelists, you overwrite the getBlacklist, if you want to add elements
you'd have to overwrite getWhitelist. with super calls, these extension
will usually boil down to a few lines of code.
Another issue which has nothing to do with the Extension approach, but
more with the implementation is what i need to do to blacklist a single
element.
The example Antoine checked in looked like this and illustrates the issue
quite well:
Set<IElementType> types = new HashSet<IElementType>();
for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
types.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
((ActivityType) gatewayType).getLiteral()));
}
This snippet removes all Elements which are Gateways.
The thing that makes this overly complex (for people who don't know the
BPMN internals) is the ElementTypeEx.wrap() call. It expects a hint on
which Type the element has. I have no clue where to get that information
as a developer who does not know about the internals. And have to resort
to trial and error.
The code i want to write is more like this (but that is just half way
there)
Set<IElementType> types = new HashSet<IElementType>();
for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
types.add(((ActivityType) gatewayType).getElementType());
}
Furthermore, not all elements are available over the ActivityType class.
If you want to blacklist looping task and subprocess you would have to
write:
tmp.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
tmp.add(ElementTypeEx.wrap(BpmnElementTypes.SubProcess_2002,
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
Note that I am wrapping the same Literal twice, because i do not know how
to wrap it correctly. This guess-work or trial and error is a major
drawback.
Unfortunately I don't know the BPMN modeler internals good enough to
provide a solution for this issue. I guess it is not so easy since most
code relevant to the examples is generated.
After a lot of writing finally here is what i would want my customization
to look like:
protected BlackList getBlacklist(){
BlackList b = super.getBlacklist();
for (ActivityType gatewayType : ActivityType.VALUES_GATEWAYS) {
b.blacklist(gatewayType)
}
return b;
}
Whitelist should look quite the same...
WhiteList and BlackList would contain the Wrapping logic for given
literals and provide their contents as a unmodifiableSet.
The Method to filter out stuff would gain a few lines, but those changes
will probably be trivial.
----
I hope these thoughts do make some sense to you and would like to hear
your comments and critics...
kind regards,
Roland Gude
|
|
|
| Re: Extending STP BPMN [message #374569 is a reply to message #374568] |
Wed, 20 February 2008 13:42 |
| Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Hi Roland,
first thanks. It feels good to have users, and even better to have users
that give feedback.
I commented inline:
Roland Gude wrote:
> Now that i have worked with the extension mechanism of BPMN modeler,
i wanted to provide some thoughts and feedback.
>
> First of all, it is really nice, that it is possible to customize the
modeler in pure Java (appart from the xml-stuff required by eclipse).
> There are however some things I did not like about the extension
mechanism.
>
> Customization includes adding and removing of elements to palette and
modelingAssistant-Popup.
> Adding and removing things from the palette works well and seems to
work without a problem.
> Unfortunately the popup bar is a bit more complicated.
> currently, if you want to remove items from the popup bar, you
overwrite Editor createDiagramEditDomain() method and provide a
blacklist of elements you do not want.
>
> The following issues arise from that:
> 1)Duplication of code
> The overwritten createEditDomain() method looks almost exactly like
its super version. Could easily be solved with factory pattern
(selecting the editdomain) or better Template method pattern (selecting
EditDomain and selecting Blacklist).
Sounds fair.
>
> 2) When you want to limit the elements available in your editor, you
need to know about all elements that are available. This is knowledge
the Developer will usually not have (at least if the user can install
extensions, which usually is the case). Another extension (which you do
not know of) can pollute your editor.
> This is a general problem of the "blacklisting" approach. This could
be solved with a "Whitelisting" approach or better even a mix of
blacklist and whitelist.
> I.e. add a method "List<IElementType> getWhitelist()" and
"List<IElementType> getBlacklist()"
> Internally you would only get those elements on your whitelist, which
are not on you blacklist. If you do not want all elements your super
class whitelists, you overwrite the getBlacklist, if you want to add
elements you'd have to overwrite getWhitelist. with super calls, these
extension will usually boil down to a few lines of code.
Ok. This seems like a very nice improvement. I will add something quickly.
>
> Another issue which has nothing to do with the Extension approach,
but more with the implementation is what i need to do to blacklist a
single element.
>
> The example Antoine checked in looked like this and illustrates the
issue quite well:
>
> Set<IElementType> types = new HashSet<IElementType>();
> for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
>
types.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
((ActivityType) gatewayType).getLiteral()));
> }
>
> This snippet removes all Elements which are Gateways.
> The thing that makes this overly complex (for people who don't know
the BPMN internals) is the ElementTypeEx.wrap() call. It expects a hint
on which Type the element has. I have no clue where to get that
information as a developer who does not know about the internals. And
have to resort to trial and error.
Apologies for the complexity here. This is a bit part of the BPMN
modeler history. We have hacked the way GMF generates visual elements to
have one visual element for all types of activities. The secondary
semantic hint is needed to specify the activity type.
>
> The code i want to write is more like this (but that is just half way
there)
>
> Set<IElementType> types = new HashSet<IElementType>();
> for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
> types.add(((ActivityType) gatewayType).getElementType());
> }
>
> Furthermore, not all elements are available over the ActivityType class.
> If you want to blacklist looping task and subprocess you would have
to write:
>
>
> tmp.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
>
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
> tmp.add(ElementTypeEx.wrap(BpmnElementTypes.SubProcess_2002,
>
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
>
> Note that I am wrapping the same Literal twice, because i do not know
how to wrap it correctly. This guess-work or trial and error is a major
drawback.
You are using the same literal twice, for the subprocess and the
activity. That's the way to go.
>
> Unfortunately I don't know the BPMN modeler internals good enough to
provide a solution for this issue. I guess it is not so easy since most
code relevant to the examples is generated.
>
> After a lot of writing finally here is what i would want my
customization to look like:
>
> protected BlackList getBlacklist(){
> BlackList b = super.getBlacklist();
> for (ActivityType gatewayType : ActivityType.VALUES_GATEWAYS) {
> b.blacklist(gatewayType)
> }
> return b;
> }
>
> Whitelist should look quite the same...
>
> WhiteList and BlackList would contain the Wrapping logic for given
literals and provide their contents as a unmodifiableSet.
>
This logic sounds good.
> The Method to filter out stuff would gain a few lines, but those
changes will probably be trivial.
Indeed.
Please follow up with this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219587
>
> ----
>
> I hope these thoughts do make some sense to you and would like to
hear your comments and critics...
Thanks again!
Antoine
>
> kind regards,
> Roland Gude
>
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
| |
| Re: Extending STP BPMN [message #611053 is a reply to message #374562] |
Sat, 09 February 2008 07:12 |
| Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Hi Roland,
first, we plan on writing a complete tutorial that we will present at
EclipseCon on the best ways to extend the modeler. We will make all
materials available.
Roland, regarding your problem with providers and your idea of using
extension points in general, I would like to bring your attention to
this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=111221
It demonstrates that using extension points is not the best way to
scale. We prefer to use Java to add or remove elements because it is
easier to tweak.
Please feel free to open an enhancement request to help extend the
modeler and give us a patch, we will look at it.
I hope this helps.
Antoine
Roland Gude wrote:
> Hi,
>
> I have been trying to customize The BPMN modeler for my needs, too.
> I have noticed that other try to do similar customizations. Therefor i
> wanted to provide what i found out here.
>
> One of the possibilities i tryed is not completely usable however,
> because it
> requires that extensions have Ids. This is not the case for the extensions
> of org.eclipse.stp.bpmn.diagram plugin. It would be nice if some Ids
> would be added.
>
> Customization steps:
> 1) write a new Plugin
>
> 2) customizing the palette
> possibility a) Create a new Extension in your plugin.xml,
> which defines a new Editor. Use the BpmnDiagramEditor
> as the class (exactly like the original editor
> extension) but use a different ID (like
> my.customized.Editor)
>
> Overwrite BpmnPaletteFactory and BpmnPaletteProvider.
> In BpmnPaletteProvider simply overwrite the
> contributeToPalette Method and let it use your newly
> created PaletteFactory.
>
>
> public class MyPaletteProvider extends BpmnPaletteProvider implements
> IPaletteProvider {
>
> public void contributeToPalette(IEditorPart editor, Object content,
> PaletteRoot root, Map predefinedEntries) {
> BpmnPaletteFactory factory = new MyPaletteFactory();
> factory.fillPalette(root);
> }
> }
>
>
>
> public class WFPaletteFactory extends BpmnPaletteFactory {
>
> public void fillPalette(PaletteRoot paletteRoot) {
> PaletteEntry pe = null;
> for (Object paletteEntry : paletteRoot.getChildren()) {
> pe = (PaletteEntry)paletteEntry;
> if (pe.getId().equals(PaletteService.GROUP_STANDARD)) {
> break;
> }
> pe = null;
> }
> if (pe != null) {
> setupStandardPaletteEntries(pe);
> }
> /*
> * * Add your contributions
> * */
>
> ToolEntry toolEntry = paletteRoot.getDefaultEntry();
> SelectionToolEx.setToolClass(toolEntry, SelectionToolEx.class);
> }
> }
>
>
> This second codeblock could be simplified if
> BpmnPalettefactory would use a method addItems() in its
> fillPalette() method. his would reduce code duplication.
>
> After you have created thos classes, add another extension
> to your plugin.xml:
> [code] <extension
> point="org.eclipse.gmf.runtime.diagram.ui.paletteProviders" >
> <paletteProvider
> class="my.package.MyPaletteProvider">
> <Priority
> name="Highest">
> </Priority>
> <editor
> id="my.ID">
> </editor>
> </paletteProvider>
> </extension>
> [code]
>
> where my.ID is the Id you previously used for your new
> editor.
>
>
>
> possibility b)
> This Possibility is a little easier in principle, but not
> fully possible with the current BpmnModeler, because The
> extensions in bpmn.diagram plugin have no Ids. This
> could however be fixed without much effort (they should
> have ids anyways)
>
> supress the extensions which provide to the palette by
> associating them with a disabled activity.
>
> to do that, put this in your plugin.xml
>
>
> <extension
> point="org.eclipse.ui.activities">
> <activity
> id="A.Never.Used.Id"
> name="Hidden activities"/>
> <activityPatternBinding
> activityId="A.Never.Used.Id"
> pattern="org.eclipse.stp.bpmn.diagram/.*"/>
> </extension>
>
> notice that this exact line will disable all extensions in
> bpmn.diagram plugin (due to the .* pattern).
>
> If the extensions would have an Id, you could
> substitute the .* with the Id of the provider you want
> to disable.
>
> 2) Customizing the ModelingAssistant:
> supress the modellingAssistant from bpmn.diagram like shown in 1b
>
> write your own modelingAssistant.
>
> create an extension in your plugin.xml
>
> <extension
> point="org.eclipse.gmf.runtime.emf.ui.modelingAssistantProviders">
> <modelingAssistantProvider
>
> class="de.dlr.rcenvironment.workflow.WFModelingAssistantProvider">
> <Priority
> name="lowest">
> </Priority>
> <editor id="my.Id">
> </editor>
> </modelingAssistantProvider>
> </extension>
>
>
> where my.Id is the Id of Editor you chose in 1a) or if you did not
> create your own editor but still use the original BpmnEditor:
> "org.eclipse.stp.bpmn.diagram.part.BpmnDiagramEditorID"
>
>
> I hope this helps.
>
> And one question for the Bpmn Developers:
> could you give Ids to your extensions, so that it would be possible to
> disable
> providers which do add to many items?
>
> kind regards,
> Roland Gude
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
|
| Re: Extending STP BPMN [message #611054 is a reply to message #374563] |
Mon, 11 February 2008 12:10 |
Roland Gude
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi,
i would favour a Java-only solution to my problems as well (I have to
write some Contributers anyways). Unfortunately i was unable to find one
until now.
The solution for the palette is pretty straight forward (overwriting the
provider, defining new editor, associating provider and editor via
plugin.xml), but it does involve a fair load of plugin.xml stuff anyway
(Or am I missing a possibility to tell the original BPMN Modeler to use
another PaletteFactory/PaletteProvider?).
Disabling the modelingAssistant popup seems to be more difficult because
an extension which adds to that extensionpoint does not seem to specify
for which eitor its contributions are meant. Instead it seems to figure
out what fits where in some Java code (which i am currently unable to find
-- correct me if i am wrong).
This means that if i write a new provider which adds some things to the
modelassistant, they are available to all editors. Therefor my customized
editor ends up with all contributions from the BPMN modeler and my
customized contribution (while i wanted to remove those from the BPMN
modeler, or at least some of them.) That is why i turned off the
modelingAssistant from bpmn.diagram (and turning of that one allone is not
possible right now due to the missing extension Ids).
If there is a Java only solution which allows me to
remove/add some contributions from/to the palette/modelAssistant
I am eager to hear it.
What is your time schedule for releasing the tutorial (can i get my hands
on it prior to eclipsecon? i know it is a lame excuse, but i need the
customized editor within a couple of weeks). If i can help with that
customization guide in any way, don't hesitate to ask. For the next two or
three weeks i will be working more or less full time on that topic anyway.
kind regards,
roland
Enhancement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=218489
a plugin.xml with Extension IDs is aattached
|
|
|
| Re: Extending STP BPMN [message #611055 is a reply to message #374564] |
Mon, 11 February 2008 13:20 |
| Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Roland Gude wrote:
> Hi,
>
> i would favour a Java-only solution to my problems as well (I have to
> write some Contributers anyways). Unfortunately i was unable to find one
> until now.
>
> The solution for the palette is pretty straight forward (overwriting the
> provider, defining new editor, associating provider and editor via
> plugin.xml), but it does involve a fair load of plugin.xml stuff anyway
> (Or am I missing a possibility to tell the original BPMN Modeler to use
> another PaletteFactory/PaletteProvider?).
I think that's good enough. At that point if you want your own palette,
you probably want your own modeling assistant, so you'll have to
subclass the editor no matter what. More below.
>
> Disabling the modelingAssistant popup seems to be more difficult because
> an extension which adds to that extensionpoint does not seem to specify
> for which eitor its contributions are meant. Instead it seems to figure
> out what fits where in some Java code (which i am currently unable to
> find -- correct me if i am wrong).
> This means that if i write a new provider which adds some things to the
> modelassistant, they are available to all editors. Therefor my
> customized editor ends up with all contributions from the BPMN modeler
> and my customized contribution (while i wanted to remove those from the
> BPMN modeler, or at least some of them.) That is why i turned off the
> modelingAssistant from bpmn.diagram (and turning of that one allone is
> not possible right now due to the missing extension Ids).
Please see the GMF bug I mentioned earlier. The provider and service
concepts are evil. All providers are executed with a strategy FORWARD,
so you can't do anything about them.
>
> If there is a Java only solution which allows me to
> remove/add some contributions from/to the palette/modelAssistant
> I am eager to hear it.
Yes, we bumped into the same problem, so we tried to stay clean from
plugin.xml madness:
You can remove elements from the modeling assistant by overriding the
editing domain and add the elements to filter.
BpmnDiagramEditDomain#setRemovedElementTypes(Set<IElementType > elementTypes)
You can override the createDiagramEditDomain() method of the
BpmnDiagramEditor subclass, and add the element types to filter there.
>
> What is your time schedule for releasing the tutorial (can i get my
> hands on it prior to eclipsecon? i know it is a lame excuse, but i need
> the customized editor within a couple of weeks).
The time schedule is EclipseCon. But we plan to work using the wiki.
If i can help with that
> customization guide in any way, don't hesitate to ask.
Please help us with that. I can create a first page, give you some kind
of outline. I'll start working on that full time soon.
For the next two
> or three weeks i will be working more or less full time on that topic
> anyway.
>
> kind regards,
> roland
>
> Enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=218489
This enhancement request is too vague to help. I assigned it to me and
commented.
>
> a plugin.xml with Extension IDs is aattached
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
| |
| Re: Extending STP BPMN [message #611058 is a reply to message #374567] |
Wed, 20 February 2008 13:12 |
Roland Gude
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Now that i have worked with the extension mechanism of BPMN modeler, i
wanted to provide some thoughts and feedback.
First of all, it is really nice, that it is possible to customize the
modeler in pure Java (appart from the xml-stuff required by eclipse).
There are however some things I did not like about the extension mechanism.
Customization includes adding and removing of elements to palette and
modelingAssistant-Popup.
Adding and removing things from the palette works well and seems to work
without a problem.
Unfortunately the popup bar is a bit more complicated.
currently, if you want to remove items from the popup bar, you overwrite
Editor createDiagramEditDomain() method and provide a blacklist of
elements you do not want.
The following issues arise from that:
1)Duplication of code
The overwritten createEditDomain() method looks almost exactly like its
super version. Could easily be solved with factory pattern (selecting the
editdomain) or better Template method pattern (selecting EditDomain and
selecting Blacklist).
2) When you want to limit the elements available in your editor, you need
to know about all elements that are available. This is knowledge the
Developer will usually not have (at least if the user can install
extensions, which usually is the case). Another extension (which you do
not know of) can pollute your editor.
This is a general problem of the "blacklisting" approach. This could be
solved with a "Whitelisting" approach or better even a mix of blacklist
and whitelist.
I.e. add a method "List<IElementType> getWhitelist()" and
"List<IElementType> getBlacklist()"
Internally you would only get those elements on your whitelist, which are
not on you blacklist. If you do not want all elements your super class
whitelists, you overwrite the getBlacklist, if you want to add elements
you'd have to overwrite getWhitelist. with super calls, these extension
will usually boil down to a few lines of code.
Another issue which has nothing to do with the Extension approach, but
more with the implementation is what i need to do to blacklist a single
element.
The example Antoine checked in looked like this and illustrates the issue
quite well:
Set<IElementType> types = new HashSet<IElementType>();
for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
types.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
((ActivityType) gatewayType).getLiteral()));
}
This snippet removes all Elements which are Gateways.
The thing that makes this overly complex (for people who don't know the
BPMN internals) is the ElementTypeEx.wrap() call. It expects a hint on
which Type the element has. I have no clue where to get that information
as a developer who does not know about the internals. And have to resort
to trial and error.
The code i want to write is more like this (but that is just half way
there)
Set<IElementType> types = new HashSet<IElementType>();
for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
types.add(((ActivityType) gatewayType).getElementType());
}
Furthermore, not all elements are available over the ActivityType class.
If you want to blacklist looping task and subprocess you would have to
write:
tmp.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
tmp.add(ElementTypeEx.wrap(BpmnElementTypes.SubProcess_2002,
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
Note that I am wrapping the same Literal twice, because i do not know how
to wrap it correctly. This guess-work or trial and error is a major
drawback.
Unfortunately I don't know the BPMN modeler internals good enough to
provide a solution for this issue. I guess it is not so easy since most
code relevant to the examples is generated.
After a lot of writing finally here is what i would want my customization
to look like:
protected BlackList getBlacklist(){
BlackList b = super.getBlacklist();
for (ActivityType gatewayType : ActivityType.VALUES_GATEWAYS) {
b.blacklist(gatewayType)
}
return b;
}
Whitelist should look quite the same...
WhiteList and BlackList would contain the Wrapping logic for given
literals and provide their contents as a unmodifiableSet.
The Method to filter out stuff would gain a few lines, but those changes
will probably be trivial.
----
I hope these thoughts do make some sense to you and would like to hear
your comments and critics...
kind regards,
Roland Gude
|
|
|
| Re: Extending STP BPMN [message #611059 is a reply to message #374568] |
Wed, 20 February 2008 13:42 |
| Eclipse User |
|
|
|
Originally posted by: atoulme.intalio.com
Hi Roland,
first thanks. It feels good to have users, and even better to have users
that give feedback.
I commented inline:
Roland Gude wrote:
> Now that i have worked with the extension mechanism of BPMN modeler,
i wanted to provide some thoughts and feedback.
>
> First of all, it is really nice, that it is possible to customize the
modeler in pure Java (appart from the xml-stuff required by eclipse).
> There are however some things I did not like about the extension
mechanism.
>
> Customization includes adding and removing of elements to palette and
modelingAssistant-Popup.
> Adding and removing things from the palette works well and seems to
work without a problem.
> Unfortunately the popup bar is a bit more complicated.
> currently, if you want to remove items from the popup bar, you
overwrite Editor createDiagramEditDomain() method and provide a
blacklist of elements you do not want.
>
> The following issues arise from that:
> 1)Duplication of code
> The overwritten createEditDomain() method looks almost exactly like
its super version. Could easily be solved with factory pattern
(selecting the editdomain) or better Template method pattern (selecting
EditDomain and selecting Blacklist).
Sounds fair.
>
> 2) When you want to limit the elements available in your editor, you
need to know about all elements that are available. This is knowledge
the Developer will usually not have (at least if the user can install
extensions, which usually is the case). Another extension (which you do
not know of) can pollute your editor.
> This is a general problem of the "blacklisting" approach. This could
be solved with a "Whitelisting" approach or better even a mix of
blacklist and whitelist.
> I.e. add a method "List<IElementType> getWhitelist()" and
"List<IElementType> getBlacklist()"
> Internally you would only get those elements on your whitelist, which
are not on you blacklist. If you do not want all elements your super
class whitelists, you overwrite the getBlacklist, if you want to add
elements you'd have to overwrite getWhitelist. with super calls, these
extension will usually boil down to a few lines of code.
Ok. This seems like a very nice improvement. I will add something quickly.
>
> Another issue which has nothing to do with the Extension approach,
but more with the implementation is what i need to do to blacklist a
single element.
>
> The example Antoine checked in looked like this and illustrates the
issue quite well:
>
> Set<IElementType> types = new HashSet<IElementType>();
> for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
>
types.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
((ActivityType) gatewayType).getLiteral()));
> }
>
> This snippet removes all Elements which are Gateways.
> The thing that makes this overly complex (for people who don't know
the BPMN internals) is the ElementTypeEx.wrap() call. It expects a hint
on which Type the element has. I have no clue where to get that
information as a developer who does not know about the internals. And
have to resort to trial and error.
Apologies for the complexity here. This is a bit part of the BPMN
modeler history. We have hacked the way GMF generates visual elements to
have one visual element for all types of activities. The secondary
semantic hint is needed to specify the activity type.
>
> The code i want to write is more like this (but that is just half way
there)
>
> Set<IElementType> types = new HashSet<IElementType>();
> for (Object gatewayType : ActivityType.VALUES_GATEWAYS) {
> types.add(((ActivityType) gatewayType).getElementType());
> }
>
> Furthermore, not all elements are available over the ActivityType class.
> If you want to blacklist looping task and subprocess you would have
to write:
>
>
> tmp.add(ElementTypeEx.wrap(BpmnElementTypes.Activity_2001,
>
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
> tmp.add(ElementTypeEx.wrap(BpmnElementTypes.SubProcess_2002,
>
BpmnPackage.Literals.ACTIVITY__LOOPING.getName()));
>
> Note that I am wrapping the same Literal twice, because i do not know
how to wrap it correctly. This guess-work or trial and error is a major
drawback.
You are using the same literal twice, for the subprocess and the
activity. That's the way to go.
>
> Unfortunately I don't know the BPMN modeler internals good enough to
provide a solution for this issue. I guess it is not so easy since most
code relevant to the examples is generated.
>
> After a lot of writing finally here is what i would want my
customization to look like:
>
> protected BlackList getBlacklist(){
> BlackList b = super.getBlacklist();
> for (ActivityType gatewayType : ActivityType.VALUES_GATEWAYS) {
> b.blacklist(gatewayType)
> }
> return b;
> }
>
> Whitelist should look quite the same...
>
> WhiteList and BlackList would contain the Wrapping logic for given
literals and provide their contents as a unmodifiableSet.
>
This logic sounds good.
> The Method to filter out stuff would gain a few lines, but those
changes will probably be trivial.
Indeed.
Please follow up with this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219587
>
> ----
>
> I hope these thoughts do make some sense to you and would like to
hear your comments and critics...
Thanks again!
Antoine
>
> kind regards,
> Roland Gude
>
>
--
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website</a>
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 05:40:07 GMT 2024
Powered by FUDForum. Page generated in 0.02258 seconds |
] 
Search
Help
Register
Login
Home
