6 Replies Latest reply on Aug 6, 2005 12:01 PM by kukeltje

    customizing TaskControllerHandler / TaskInstance

    kukeltje

      Hi,

      From a really nice guy from Germany I got the question to help him extending jBPM with an xforms ui (Finally!!!!) From the docs I got imo double signals. One is that I could put a custom task controller on my tasks like

      <task name="clean ceiling">
       <controller class="com.yourcom.CleanCeilingTaskControllerHandler">
       -- here goes your task controller handler configuration --
       </controller>
      </task>


      I could put my own config in there by either bean, field org constructor config-type. But it seems that the TaskInstance class still wants taskFormParameters, so this is usable only for minor deviations from the default taskinstance behaviour right?

      If I realy want other behaviour, like not using taskFormParameters for displaying task etc, I need to override the taskInstance behaviour and create probably my own TaskInstance like it says in http://docs.jboss.com/jbpm/v3/userguide/taskmanagement.html#customizingtaskinstances

      Since that basically overrides the default Task behaviour I can also put anything in the task as a config but use just

      <task name="clean ceiling">
       <controller>
       -- here goes your task controller handler configuration --
       </controller>
      </task>


      Ronald
      (as a jBPM user ;-) )

        • 1. Re: customizing TaskControllerHandler / TaskInstance
          tom.baeyens

          The task controller is to give you more flexibility in the data handling. The task controller is used to fetch the data from the process variables and transform them into task form parameters. It is not required that the task form parameters have a relation with process variables.

          In the other direction, when the task parameters are submitted, this could/should lead to updates in the process variables. but a custom implementation of the task controller here does not have to keep the one-on-one relation between task parameters and process variables. (e.g. the form could submit 2 integer values. the task controller could add them and store the result in a process variable)

          is there some other behaviour that you want to customize ?

          regards, tom.

          • 2. Re: customizing TaskControllerHandler / TaskInstance
            kukeltje

             

            "tom.baeyens@jboss.com" wrote:
            The task controller is to give you more flexibility in the data handling. The task controller is used to fetch the data from the process variables and transform them into task form parameters. It is not required that the task form parameters have a relation with process variables.


            With form parameters you mean the form parameters as used by the default webapp. That is at least the impression I got when trying to implement a task controller.

            "tom.baeyens@jboss.com" wrote:

            In the other direction, when the task parameters are submitted, this could/should lead to updates in the process variables. but a custom implementation of the task controller here does not have to keep the one-on-one relation between task parameters and process variables. (e.g. the form could submit 2 integer values. the task controller could add them and store the result in a process variable)


            Again, task parameters as posted by the default webbap. right?

            "tom.baeyens@jboss.com" wrote:

            is there some other behaviour that you want to customize ?


            Yes, A completely different type of form, namely an xform. I'm currently working on this with a party that has a server-side xforms engine (applet and AJAX compliant version are being worked on). A different task instance handler seems more appropriate then creating a mapping between task form parameters and the way this xforms engine works internally.

            Ronald

            • 3. Re: customizing TaskControllerHandler / TaskInstance
              tom.baeyens

              but an xform takes as input a set of parameters (in the form of an xml document, right?) and can produce an xml document upon submission, right ?

              i don't yet see the problem...

              the TaskController is only to decouple the process variables from the parameters that are used in the forms. it does not contain any UI related stuff. maybe the name is wrong. it should be called TaskDataHandler or something like that.

              to support xforms, i think the default task controller behaviour should be sufficient. you fetch a number of parameters from the task instance, create an xml document from that and feed it into the xform generator, together with the xform. then the submitted xml document is parsed and the parameters that are extracted from the submitted xml document are submitted in the taskinstance. no ?

              regards, tom.

              • 4. Re: customizing TaskControllerHandler / TaskInstance
                kukeltje

                I could give it a try, But I have to configure a specific taskDataHandler on every task, well at least the tasks that contain xforms.

                Since we/they are also thinking of generating xforms on the fly based on processvariables and types of variables (Lists, Maps get a dropdown box e.g., date get's a nice calendar item) almost all forms will be xforms orientend.

                Instead of configuring the taskDataHandler on each task, it would be better/easier to override the default controller (handler)

                btw, are taskFormParameters not just the form elements and buttons? THat is the impression I got. I tried passing other xml data but got errors on that level. That is why I tried switching to the instance handler

                • 5. Re: customizing TaskControllerHandler / TaskInstance
                  tom.baeyens

                  task form parameters are indeed a bit more then just a value. they also contain access and some other related data. but still UI neutral.

                  the task form parameter is a container for all the data that was necessary to create the html form. can you see what kind of data you need extra in there to add support for xforms ?

                  it would indeed make sense to create a configuration in the jbpm.properties that specifies the default TaskController behaviour. make a jira issue for this if you need it and assign it to 3.1

                  regards, tom.

                  • 6. Re: customizing TaskControllerHandler / TaskInstance
                    kukeltje

                    All the properties like readonly etc... are in the xform definition, see http://www.xformsinstitute.com/lesson3.php, so no properties like these are needed, at least not for rendering. Maybe if additional validation is done on the jBPM side (e.g. throw an exception if a readonly variable is tried to be set).

                    There is the need for a mapping between an element in the result xml document and a process variable. This will probably be an xpath mapping.

                    Besides this, you get all kinds of rendering options for controls: http://www.xformsinstitute.com/lesson4.php

                    Look at the bottom of the previous link to see how `

                    <select1 ref="my:name/@title"><label>Title:</label></select1>
                    <input ref="my:name"><label>Name:</label></input>
                    <secret ref="my:password"><label>Password:</label></secret>
                    <textarea ref="my:address"><label>Address</label></textarea>
                    <trigger><label>Push Me</label></trigger>
                    


                    will be rendered.