-
1. Re: customizing TaskControllerHandler / TaskInstance
tom.baeyens Aug 5, 2005 8:30 AM (in response to kukeltje)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 Aug 5, 2005 9:33 AM (in response to 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 Aug 5, 2005 10:45 AM (in response to kukeltje)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 Aug 5, 2005 11:07 AM (in response to 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 Aug 5, 2005 2:31 PM (in response to kukeltje)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 Aug 6, 2005 12:01 PM (in response to 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.