-
1. Re: splitting node behaviour ?
mvaldes Aug 8, 2007 12:13 PM (in response to tom.baeyens)I understand your point but this will end up into probably too many interfaces :-)
I think was good to split into two interfaces between Node implementations and actions (different concepts) but I'm not sure that a similar update should be applied to waitstates vs automatic activities. Both are nodes that requires a behaviour (that was pretty generic, once a new node type is created just implement de NodeBehaviour inter.)
In which use case are you thinking about for the getSignals() method ?
regards,
Miguel Valdes -
2. Re: splitting node behaviour ?
csouillard Aug 9, 2007 11:10 AM (in response to tom.baeyens)I understand this approach but I am not sure to well understand how it could run in the pvm ?
Does it mean that the pvm execution should take care about these two different NodeBehaviour ?
Beacuase in one case (automatic) signal must not be called... As I am not sure to completely understand the new pvm execution maybe the answer is trivial as signal method is indirectly called by user...
Maybe these new classes could be abstract classes available in pvm but not used...
Users (module developer) could choose for a NodeBehaviour between these two and only implement execute for automatic and implement execute signal for Wait...
Charles -
3. Re: splitting node behaviour ?
tom.baeyens Aug 10, 2007 6:43 AM (in response to tom.baeyens)"csouillard" wrote:
I understand this approach but I am not sure to well understand how it could run in the pvm ?
Does it mean that the pvm execution should take care about these two different NodeBehaviour ?
Beacuase in one case (automatic) signal must not be called... As I am not sure to completely understand the new pvm execution maybe the answer is trivial as signal method is indirectly called by user...
Maybe these new classes could be abstract classes available in pvm but not used...
Users (module developer) could choose for a NodeBehaviour between these two and only implement execute for automatic and implement execute signal for Wait...
Charles
every node must have an execute method implementation. but only methods that can be wait states must also have a signal method. -
4. Re: splitting node behaviour ?
tom.baeyens Aug 10, 2007 6:46 AM (in response to tom.baeyens)"mvaldes" wrote:
In which use case are you thinking about for the getSignals() method ?
In task forms where buttons could be shown for each leaving transition. -
5. Re: splitting node behaviour ?
tom.baeyens Aug 10, 2007 6:48 AM (in response to tom.baeyens)"csouillard" wrote:
Maybe these new classes could be abstract classes available in pvm but not used.
that might be a good alternative. we could put them in the org.jbpm.pvm package.impl package, and reference/suggest them from the javadocs of the node behaviour interface. -
6. Re: splitting node behaviour ?
mvaldes Aug 10, 2007 10:12 AM (in response to tom.baeyens)
In task forms where buttons could be shown for each leaving transition.
I see. In fact I used to do that by leveraging enum variables in Bonita rather than buttons. This variable is evaluated afterwards in a transition condition.
In this case getSignals is not required :-)
regards,
Miguel Valdes