Task Forms

[dmlloyd]

Currently, the JSF Task Forms have a lot of requirements about the circumstances of their execution. For example, they assume that they are loaded from the /jbpm-console/participant/ path, so all their references are relative to there.

They also assume the existance of "taskBean", the presence of certain images in the "../images" path, and the presense of "../css/jbpm.css". And finally, they rely on structural details of the taskBean, such as action methods.

I propose that rather than having this information in the form (and thus putting significant restrictions on how the forms are displayed and used), each of those constructs could be replaced by a combination of a set of XML elements that perform each function, and using EL to import significant variables right into the task form space; for example, assuming an "tf" prefix for "task form":

<img src="../images/formline.jpg" width="100%" height="24" border="0" alt=""/>

Becomes:

<tf:formline/>

And:

<input jsfc="h:inputText" value="#{taskInstanceBean.variables['paymentId']}" />

Becomes:

<input jsfc="h:inputText" value="#{paymentId}"/>

And finally:

<input type="submit" jsfc="h:commandButton" id="transitionButton" action="#{taskInstanceBean.saveAndClose}" value="Save and Close Task"/>
<input type="submit" jsfc="h:commandButton" action="#{taskInstanceBean.save}" value="Save"/>
<input type="submit" jsfc="h:commandButton" action="#{taskInstanceBean.cancel}" value="Cancel"/>

Becomes:

<tf:transitionButtons/>

...or can be left out altogether.

Also, the task form need not include <h:form> tags, since this is really implicit; by providing this ourselves, we can add any hidden inputs we need to, and this frees the form designer from worring about the implementation details of the web application that utilizes the forms.

Opinions?


Also, one other unrelated problem is that some of the example task forms have multiple elements with the same ID, which is not allowed by either JSF or HTML.

[tom.baeyens]

i like the

<tf:formline/>

. this makes the location of the form line image configurable in one spot in the web application.


but i'm not sure if the other proposals are appropriate. making the forms more loosely coupled to their runtime environment is indeed a plus.

i see some potential downsides...

Using EL to access variables is a good thing (maybe they already are included in the lookup). But you should take into account that users can define variable names with spaces. In that case we need another lookup mechanism.

Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies.

We should avoid that people have to learn the jBPM Form Layer apart from JSF and Facelets. At least, this was the idea when designing the forms solution.

Also with the buttons, the idea was that the graphical designer will generate those. After initial generation of the form by the gpd, the users now are able to customize the boring form layout to their own wishes.

By just using plain JSF/Facelets constructs, it seems much more flexible for users to start tweaking the graphical form.

On the other hand, if users don't customize the forms, they can always re-generate after they made some updates that have an impact on the form.

So this explains why I was not too concerned with usability of the form constructs. My main concern was lowering the learning curve. The other important thought is that mostly, users will generate the forms and will not be looking at the form code.

In my current design, they only have a problem of loosing synchronization if they start customizing the form and then adding transitions, variables or other changes that have an impact on the form. Then the user is placed for the dillemma of regenerating and loosing updates or maintaining his changes manually in the form.

I mainly wanted to give you the background of why i designed it this way.

In summary, my advice would be to only go for the formline change. But of course, you are free to override my opinion or try to change it.

[dmlloyd]

Using EL to access variables is a good thing (maybe they already are included in the lookup). But you should take into account that users can define variable names with spaces. In that case we need another lookup mechanism.

Ok, in that case probably it's more appropriate to say:

<h:inputText value="#{var['payment ID']}"/>

Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies.

But requiring certain beans to be present is a nuicance. I don't want the task forms to be expecting certain managed beans, because this restricts my ability to make changes.

We should avoid that people have to learn the jBPM Form Layer apart from JSF and Facelets. At least, this was the idea when designing the forms solution.

I wouldn't want to create a vastly new syntax or anything. But generally speaking, using a variety of component libraries is a very normal pratice that Facelets users are used to. It makes perfect sense to provide a component library for dealing with task forms; it's the most natural integration with Facelets in my opinion.

Also with the buttons, the idea was that the graphical designer will generate those. After initial generation of the form by the gpd, the users now are able to customize the boring form layout to their own wishes.

I still maintain that some type of custom component is needed here. Better that the user could say:

<tf:button transition="to receive payments" .../>

...but still be able to specify all the standard JSF button attributes as well, including images, ID, styleClass, etc.

By just using plain JSF/Facelets constructs, it seems much more flexible for users to start tweaking the graphical form.

I agree.

On the other hand, if users don't customize the forms, they can always re-generate after they made some updates that have an impact on the form.

So this explains why I was not too concerned with usability of the form constructs. My main concern was lowering the learning curve. The other important thought is that mostly, users will generate the forms and will not be looking at the form code.

With the form designer generating the inital form, I don't think usability will be a problem at all. If the user gets "lost" they can always just regenerate. In which case, the next most significant concern is implementation. I don't want to be in a situation where we've painted ourselves into a corner, just because it was a convenient first pass of an implementation. At the very least, I want to remove the usage of "taskBean" from the generated forms completely, and also I want to remove anything having to do with page navigation (in this case, action="" on the buttons).

[tom.baeyens]

Ok, in that case probably it's more appropriate to say:

<h:inputText value="#{var['payment ID']}"/>

Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies.

But requiring certain beans to be present is a nuicance. I don't want the task forms to be expecting certain managed beans, because this restricts my ability to make changes.

I see. But you have to fix something anyway. Either a bean or a special variable resolver.

The var[...] notation is more concise.

I have a slight preference for a bean because developers will understand the bean way more rapidly. The special variable resolver might seem like magic. Something which is not appreciated in the post-ejb2 era :-)

Afaik, all my arguments are on the table. Now you can just decide what you think is best.

<tf:button transition="to receive payments" .../>

...but still be able to specify all the standard JSF button attributes as well, including images, ID, styleClass, etc.

Yes that solves my problem and is the best solution.


As for the task form generation planning, Koen is now finishing a fix for a bug that disabled the task form generation in 3.2.Alpha1. Once that is done, i want to release 3.2.Alpha2 (hopefully before the end of the week). That version should give you a good basis for testing the task forms in the web console.

[kukeltje]

I have a slight preference for a bean because developers will understand the bean way more rapidly. The special variable resolver might seem like magic. Something which is not appreciated in the post-ejb2 era :-)

Me to.

......Yes that solves my problem and is the best solution.

Agree, well... it still leaves the issue of what to do with forms that are adapted but get another transition. Should the form-generator take this into account and add something? One of the things I hated in the staffware forms things was the 'yes you can change the form once it is generated it, but do not think you can change things in the proces

[tom.baeyens]

"kukeltje" wrote:
Agree, well... it still leaves the issue of what to do with forms that are adapted but get another transition. Should the form-generator take this into account and add something? One of the things I hated in the staffware forms things was the 'yes you can change the form once it is generated it, but do not think you can change things in the proces

keeping them in sync automatically is possible but a looooooooooooooooooooooooooooooooooot of work. so i think users will have to accept that we can't develop an eclipse wysiwyg forms editor on top of the facelets-jbpm-forms language.

it would be good if the designer could remember (in the gpd.xml) wether forms have been generated and customized. so that the forms can be automatically re-generated when the process is saved and when the user didn't yet apply any customizations... not sure if we can make that approach to be a robust solution, though.

[kukeltje]

I did not mean keeping them in sync 2-way..... and not at alll develop a wysiwyg editor (look at exadel, they have some nice functionality, even in the free one)

Robustnes sould be kept in mind, otherwise we get a lot of iritated users with comments like "What the F* happened to my form". I think we should think this over

[koen.aers]

Maybe we should take the approach as it is done in the tooling of the Eclipse EMF project. These tools generate Java artifacts that you can customize afterwards. All generated artifacts have a '@generated' annotation and they keep being regenerated (thus erasing possible customizations) unless you remove the '@generated' or replace it by '@generated NOT'.
Would this be acceptable?

Regards,
Koen

[tom.baeyens]

merging the diffs by using markers is a pain. not worthed imo. I propose that we first implement generation without synchronization and see what kind of feedback we get on that.

the only thing that i think we should make easier is automatic regeneration of forms if form data is changed.

can we (and if so, how) store the form generation data into the processdefinition or gpd xml file.

the most frequent use case is a task without a controller, with several data items in the form (directly onto the process variables). In that case, regeneration of the form would imply that the user has to enter all the variables again. This is because we take the variables of the controller as a starting point. But if there is no controller, you have to start entering the form data items from scratch each time.

[kukeltje]

merging the diffs by using markers is a pain. not worthed imo.

hmm.... what about generating a new form with and then allow the user to use the diff functionality of eclipse?

I propose that we first implement generation without synchronization and see what kind of feedback we get on that.

I agree

the only thing that i think we should make easier is automatic regeneration of forms if form data is changed.

And the place of the generate forms (it's on the advanced tab but is almost 'required' now)

In that case, regeneration of the form would imply that the user has to enter all the variables again.

???? Can't this be automatically populated? (I cannot use the gpd from cvs head now, it's not functional so I cannot test this)

[tom.baeyens]

"kukeltje" wrote:

merging the diffs by using markers is a pain. not worthed imo.

hmm.... what about generating a new form with and then allow the user to use the diff functionality of eclipse?

under assumption that the diff editor is easy to bring up, that would be a very good idea.

"kukeltje" wrote:

the only thing that i think we should make easier is automatic regeneration of forms if form data is changed.

And the place of the generate forms (it's on the advanced tab but is almost 'required' now)

What do you mean with 'almost required' ?

"kukeltje" wrote:

In that case, regeneration of the form would imply that the user has to enter all the variables again.

???? Can't this be automatically populated? (I cannot use the gpd from cvs head now, it's not functional so I cannot test this)

We're doing our best to get the next alpha out the door. There you should be able to see the form generation in action. You can already check the Alpha1, but in my case this didn't work (Koen says it works for him:-)

[kukeltje]

with almost required I mean that there is no automagically runtime generated form anymore. Designing a process and running it, requires forms to be generated. Therefor it should not be under the advanced section.

Koen probably had to much Dutch beer and sees things that in reality are not there.