-
1. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 27, 2008 7:11 AM (in response to trouby)"trouby" wrote:
I'm finding myself writing a lot of processes nodes that make a usage of the same java code but with very simple modifications,
Then why not re-use the same handler code?
Make sure the handler has a field/setter and then when you use the handler, pass in a parameter to modify the behaviour. Doesn't even need a custom node implementation. -
2. Re: Less coding by custom nodes/jrules/etc...
trouby Feb 27, 2008 10:51 AM (in response to trouby)Hey,
Thanks for answering,
Few reasons:
1) In the future, it'll be easier to customize things visually through nodes, selecting handles is not nice as dragging nodes,
2) Customizing parameters of nodes can be done visually, handlers receive info as method parameters, which is not nice as visual form fields (btw, I don't use handlers at all, I use expressions and invoke Seam components, but it's about the same implementation)
3) I have too much information to pass, it'll be easier to pass it via a new structure of the node in the processdefinition.xml
So, for the start, is it possible to customize nodes? if so, is it documented? somehow? somewhere? samples? :)
Thanks,
Asaf. -
3. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 27, 2008 1:29 PM (in response to trouby)"trouby" wrote:
So, for the start, is it possible to customize nodes? if so, is it documented? somehow? somewhere? samples? :)
If you haven't yet, then download the jBPM source code (http://docs.jboss.com/jbpm/v3/userguide/gettingstarted.html#cvsaccess) and check out the unit test code and samples - there may well be something to guide you there.
The userguide has also got some info: http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#customnodebehaviour
Hope these help. -
4. Re: Less coding by custom nodes/jrules/etc...
trouby Feb 27, 2008 3:36 PM (in response to trouby)Hey,
I already read the whole doc from top to bottom :)
I'll try to download the source code, hopefully there's a full sample (custom node/process that make a usage of the custom node, etc...)
I thought that this is something very common,
Thanks,
Asaf. -
5. Re: Less coding by custom nodes/jrules/etc...
kukeltje Feb 27, 2008 5:46 PM (in response to trouby)Customized node via delegation classes yes, custom nodes that have their own 'look and feel' in the GPD no.. Although the esb node is a kind of intermediate.
No this is not common. Since jBPM can be functionally extended with actions on nodes in a way that custom nodes are not often needed. -
6. Re: Less coding by custom nodes/jrules/etc...
trouby Feb 27, 2008 8:35 PM (in response to trouby)Hey,
Can't I just have my own node type? maybe extended from the generic node available in JBPM
like there's / <task-node> I would like to have my own node tag, fully described differently, with different tags and parameters?
Thanks,
Asaf. -
7. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 28, 2008 5:53 AM (in response to trouby)"trouby" wrote:
Hey,
Can't I just have my own node type? maybe extended from the generic node available in JBPM
like there's <node> / <task-node> I would like to have my own node tag, fully described differently, with different tags and parameters?
Then you'll also have to customise jBPM so that the XML parses correctly, add the necessary code to the GDP so the design can be rendered etc.
Sure, it can be done, but sounds to me like a whole lot of effort for little reward. -
8. Re: Less coding by custom nodes/jrules/etc...
trouby Feb 28, 2008 9:45 AM (in response to trouby)Hey,
Well, the designer is not so easily extend able, I better leave it for now,
What about extending the default node, but having more tags specified in its body? aint there an example for that? I hope there is, I also hope that the engine delegates the XML tags to the node execution itself so I can read them, if this is possible, then great.
Anyone?
Thanks,
Asaf. -
9. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 28, 2008 11:20 AM (in response to trouby)"trouby" wrote:
Well, the designer is not so easily extend able, I better leave it for now,
Wise decision..."trouby" wrote:
What about extending the default node, but having more tags specified in its body?
You could, but that'll still mean changing the core jBPM source to have them parsed."trouby" wrote:
I also hope that the engine delegates the XML tags to the node execution itself so I can read them, if this is possible, then great.
The tags are delegated to the node class, but at the time the definition is read from the XML source - so not at execution time. (At least, I'm pretty sure that's how it is.)
You could add configuration in the jbpm.cfg.xml if you want to defer evaluation till runtime - check out http://docs.jboss.com/jbpm/v3/userguide/mail.html#mailserverconfiguration and see how that's used to configure email nodes.
e.g.<jbpm-configuration> ... <string name='resource.mail.properties' value='jbpm.mail.properties' /> </jbpm-configuration>
[/url] -
10. Re: Less coding by custom nodes/jrules/etc...
kukeltje Feb 29, 2008 5:05 AM (in response to trouby)"trouby" wrote:
What about extending the default node, but having more tags specified in its body?
You could, but that'll still mean changing the core jBPM source to have them parsed.
No not needed. just add an action to the node to give it the behaviour you want. No need to change any core jbpm source.The tags are delegated to the node class, but at the time the definition is read from the XML source - so not at execution time. (At least, I'm pretty sure that's how it is.)
If you put xml tags in as params, they'll be passed, runtime, to your node implementation in the form of an XML Document object. regardless of which tags you put in. See http://docs.jboss.com/jbpm/v3/userguide/jpdl.html#configurationofdelegations
How you parse the content of what is in there is completely up to the developer -
11. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 29, 2008 7:09 AM (in response to trouby)"kukeltje" wrote:
See http://docs.jboss.com/jbpm/v3/userguide/jpdl.html#configurationofdelegations
How you parse the content of what is in there is completely up to the developer
I had another look at that and came up with the following:<process-definition xmlns="" name="TestProcess"> <start-state name="startstate"> <transition to="node1" name="ok"> <action name="Test1" class="TestHandler" config-type="constructor"> <blob>This is some constructor config data</blob> </action> <action name="Test2" class="TestHandler" config-type="field"> <blob>This is some field config data</blob> </action> <action name="Test3" class="TestHandler" config-type="bean"> <blob>This is some bean config data</blob> </action> </transition> </start-state> <node name="node1"> <transition to="end"></transition> </node> <end-state name="end"></end-state> </process-definition>
andimport org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.jbpm.graph.def.ActionHandler; import org.jbpm.graph.exe.ExecutionContext; public class TestHandler implements ActionHandler { private static Log log = LogFactory.getLog(TestHandler.class); public String blob; public TestHandler() { log.debug("Default constructor"); blob = "default"; } public TestHandler(String xml) { this(); log.debug("Config constructor"); configure(xml); } public void configure(String xml) { log.debug("Parse: " + xml.trim()); } public void setBlob(String blob) { log.debug("Setter"); this.blob = blob; } public void execute(ExecutionContext executionContext) throws Exception { log.debug("Execute: " + blob); } }
Hope that helps :) -
12. Re: Less coding by custom nodes/jrules/etc...
kukeltje Feb 29, 2008 8:31 AM (in response to trouby)correct and String blob can also be a List, Map, Document, whatever.... see the unittests for all kinds of examples
-
13. Re: Less coding by custom nodes/jrules/etc...
trouby Feb 29, 2008 11:43 AM (in response to trouby)Cool,
btw, the reason I was trying to do everything through different type of nodes is the designer,
At the end, I would like to see a designer with different type of nodes that are draggable, and have different behavior,
With the suggested way here, in the future, the designer will still only have 1 generic type node (as available now) but with different actions, which is not nice as having different guitable nodes :-)
Cool, I'll use actions for now as new nodes seems to be too complicated
(although I'm pretty sure in the doc it is written that it is possible to add new nodes easily)
Thanks for the answers guys, really.
Thanks,
Asaf. -
14. Re: Less coding by custom nodes/jrules/etc...
pojomonkey Feb 29, 2008 1:56 PM (in response to trouby)"trouby" wrote:
(although I'm pretty sure in the doc it is written that it is possible to add new nodes easily)
This is where you learn that 'easy' is a relative term - no doubt whoever wrote that does consider it 'easy' - doesn't mean it actually is easy. LOL.