7 Replies Latest reply on Mar 23, 2007 11:11 AM by Ronald van Kuijk

    jBPM JSF component design: actions

    David Lloyd Master

      One major category of components that are needed by any jBPM web application are components that do things - like starting processes, taking transitions, adding comments, etc.

      After pondering the practical use of such components, I think that the best way to provide this kind of capability is by providing a set of standard tags that equip ActionSource components with an ActionListener that carries out the action, and executes the navigation afterwards. This leaves the decisions regarding what type of controls to use, or how they should be rendered, complete up to the user.

      For example (assume that the appropriate tag library is loaded with prefix "j"):

      <h:commandButton value="Start Process">
       <j:startProcessAction process="#{process}"/>
      </h:commandButton>

      or:
      <h:inputTextarea value="#{requestScope.comment}"/>
      <h:commandButton value="Save Comment">
       <j:saveCommentAction task="#{task}" comment="#{requestScope.comment}"/>
      </h:commandButton>


      The user can configure the navigation rules via JSF, Seam, or any other navigation handler.

      By using actions like this, the user can create page controls that accept input (like the comment example above), without even having to use a backing bean. Can't get much easier than that!

        • 1. Re: jBPM JSF component design: actions
          David Lloyd Master

          Ok, I've compiled a list of JSF actions that I plan to implement for the action handler tags.

          * startProcess - start an instance of a process
          * cancelProcess - cancel a whole process instance
          * startTask - mark a task as started
          * completeTask - mark a task as complete, with an optional transition attribute
          * addComment - add a comment to a task or a token
          * assignTask - assign a task to an actor, a swimlane, or pooled actors
          * cancelToken - cancel a token
          * moveToken - move a token to a new node
          * signalToken - signal a token
          * updateVariable - update a process variable
          * updateProcessInstance - update process instance information
          * updateToken - update token information
          * updateTask - update task information
          * suspendToken - suspend a token
          * resumeToken - resume a suspended token
          * deployProcess - deploy a process
          * jbpmAction - a general tag, similar to <f:actionListener/> but provides a JbpmContext parameter to the action (maybe provide a means to inject other information like TaskInstance, Token, etc.)

          Are there any other basic actions that I'm not thinking of here? Comments welcome as well.

          • 2. Re: jBPM JSF component design: actions
            Tom Baeyens Master

            this is a good idea!

            but in the coming weeks, keep your focus on stability.

            regards, tom.

            • 3. Re: jBPM JSF component design: actions
              David Lloyd Master

              The actions are all ported into jbpm4jsf. I'm going to work on testing for now. Also I'm going to try to find a home for the online taglib documentation as well. I have a task list for all the actions and components that are implemented within jbpm4jsf in issue JBPM-567 [1].

              Also I'll be rounding out Gravel [2] with the other components that were used by the 3.2 web console.

              Finally, I'll be getting versions of these jars up on the repository so that they can be used without having to build them from source.

              [1] http://jira.jboss.com/jira/browse/JBPM-567
              [2] http://labs.jboss.org/portal/gravel/?prjlist=false

              • 4. Re: jBPM JSF component design: actions
                Ronald van Kuijk Master

                cool, compliments.

                We should file a jira issue though against RHDS for making these components render correctly when used in desiging JSF/Facelets pages. Agreed?

                • 5. Re: jBPM JSF component design: actions
                  Ronald van Kuijk Master

                  btw, I'm making a ajax aware gauge/dial in SVG based on http://technology.amis.nl/blog/index.php?p=325. This does not require images to be generated on the server side, just one small number has to be returned. Could we do something with this?

                  • 6. Re: jBPM JSF component design: actions
                    David Lloyd Master

                     

                    "kukeltje" wrote:
                    We should file a jira issue though against RHDS for making these components render correctly when used in desiging JSF/Facelets pages. Agreed?


                    Interesting idea, but for one detail: All the aforementioned components (and also the new ones I've added to the list since then) are action listeners, and as such they don't actually render anything onscreen - they just facilitate the integration with jBPM. That's one of the strengths of the architecture: you can use standard GUI components, or you can use components from the component library of your choice.

                    So basically, there would be nothing to add to RHDS for this. Gravel on the other hand would have to be added, since that is comprised largely of visible components.

                    • 7. Re: jBPM JSF component design: actions
                      Ronald van Kuijk Master

                      even cooler ;-) I have to apologize then for not looking into the implementation (yet) Busy at my official employer and just some time to read the forum not check the code.