3 Replies Latest reply on Jan 25, 2007 10:53 AM by tom.baeyens

    methods for building a process graph

    tom.baeyens

       

      "Miguel" wrote:

      - I have added a new method to the Node.java file just to be able to add actions to Nodes. The code allowing to "fire" those actions was already there but it didn't find a way to add actions to a node, any clue on this ?

      Miguel


      regards, tom.

        • 1. Re: methods for building a process graph
          tom.baeyens

          those methods indeed still are to be added. add them as appropriate.

          it would be great if for the whole model, there is on strategy on bidirectional references.

          my current approach is that in case of 1-n relationships, i always create addXxxx methods (apart from the traditional getters and setters). those add methods maintain the back pointer of the element being added.

          of course, this can break down in several places. but i have found it a good balance between simplicity of implementation and functionality.

          i once implemented a framework for managing bidirectional relations that kept all the references in sync and cleared the backpointers when an element was removed from a collection. ended up far too complex. both for usage and implementation.

          also, as much as possible, keep in mind that these objects and collections will have to be persisted with JPA (or hibernate). although making the model persistable is something that i would like to do in a second stage.

          • 2. Re: methods for building a process graph

            I remember having also some problems with bidirectional relationships in the past so I agree with your approach of using 1-n as much as possible.

            For sure, persistence is also one of the things I care about. All this stuff must be easily persistable using EJB3 and or directly hibernate in your case.

            I will try to take some time to work on adding methods related to actions and events. However I would like to know your feeling about:

            - I noticed that the current "fire" and "executeEvent" methods in Execute.java file are handling events which can contain one or more actions. As an event has a particular event type (i.e: node-enter, node-leave...) what is the purpose of having multiple actions in a event of type node-enter for instance ?

            - What is the purpose of expression and stateful attributes defined in the Action.java file ?

            regards,
            Miguel Valdes

            • 3. Re: methods for building a process graph
              tom.baeyens

               

              "mvaldes" wrote:
              - I noticed that the current "fire" and "executeEvent" methods in Execute.java file are handling events which can contain one or more actions. As an event has a particular event type (i.e: node-enter, node-leave...) what is the purpose of having multiple actions in a event of type node-enter for instance ?


              this groups all the actions that have to be executed at e.g. node entrance. for each event that fires during process execution, the engine just executes the list of actions for that event in order.

              "mvaldes" wrote:

              - What is the purpose of expression and stateful attributes defined in the Action.java file ?


              an action is the description (part of the process definition) of what user code has to be executed when a certain process event occurs.

              if you specify an expression, it will be a JSF EL type of expression with method binding. so you could do like expression="#{myPersonVar.address.street.diggForSewer}" which navigates the object model before invoking the real method that represents this action. the way that the first term is resolved is configurable by specifying an implementation for an interface.

              the attributes are statefull because it's part of the process definition. so 1 action for all executions of this action.

              currently in jbpm i instantiate a new actionhandler and inject the configuration for each execution. we could/should think about pooling those action handlers in the long run. or at least have a property that allows process designers to specify actions as stateless in which case they can be shared and reused.