6 Replies Latest reply on Aug 10, 2007 10:12 AM by mvaldes

    splitting node behaviour ?

    tom.baeyens

      i think we need an extra method on node behaviour:

      Set<String> getSignals();


      so that external clients can check which signals they can give on an execution.

      adding a second method that is not necessary for automatic activities, i start to wonder if we should split the NodeBehaviour in two separate interfaces. otherwise we always need to throw UnsupportedOperationExceptions all the time...

      1 for automatic activities with only the execute method. a second interface would extend that with the 2 methods for signals: getSignals and signal

      but how to call those interfaces ? AutomaticActivity and Waitable ? hmmmm

      thoughts ?

        • 1. Re: splitting node behaviour ?

          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

            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

               

              "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

                 

                "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

                   

                  "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 ?

                     


                    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