purpose of the jBPM webapp

[tom.baeyens]

just wanted to discuss the purpose and design goals of the jbpm webapp. i'll start by giving our opinion. then i'm interested in yours.

purposes:
======
1) Tasklist UI for workflow participant enabling rapid prototype development
2) Monitoring
3) Administration
4) Demonstration of the jBPM core software

currently, there is no distinction and authorization between the different purposes of the webapp. that is mainly because demonstration of the jbpm capabilities is the most important. later on, we might think of separating the components of the webapp in some way so that we can add authorization, but for now, this is not a priority, i think.

design goals:
=========
1) simple as possible so that developers can explore and reuse parts
2) as much as possible should be packaged as jsf ui component so that other users' webapps and portal apps can reuse them.

task forms:
=======
There's a whole range of solutions possible. At the one end, a user specifies just a list of fields and the form generator builds a whole form for this. This solution makes it hard or impossible to customize the look and feel. On the other end, there is the complete cusomizable form with e.g. JSP's but that requires detailed and more difficult specification of each form.

What i want to do with jBPM web app is support both ends. Meaning that you should be able to just specify the list of fields to generate a form that simply creates a flat list of form fields. And on the other end, if you want more customizability, you should be able to specify a JSP page or something of that kind.

So Ronald, to comment on your proposal of extending the types of fields. I think it adds value to what we currently have. But I would think it is more important to work out first the flexible solution on the other end. Once that is done, we can see which additions of customisation parts make sense in the simple form specification... makes sense ?

thoughts ?

regards, tom.

[kukeltje]

There is already a flexible version in my tree. Each task can have it's own jsp, based on the task(node) name. in addition changes to the taskbean make it possible to do:

<h:inputText id="user-email" value="#{taskBean.fields['email'].value}" size="25"
 styleClass="required"></h:inputText>

or

<t:inputCalendar
 id="user-date-of-birth" renderAsPopup="true"
 renderPopupButtonAsImage="true" popupTodayString="Vandaag: "
 value="#{taskBean.fields['date-of-birth'].value}"
 styleClass="required" maxlength="10" size="13"
 popupDateFormat="dd-MM-yyyy" readonly="true" />

or using selectOneRadio or whatever.

is that flexible enough?

Besides this, there can be specific pages for transitions with things like 'thank-you-for-ordering.jsp' or whatever.

[tom.baeyens]

does the user have to deploy the custom task jsp's in a separate webapp or are those part of the jbpm process definition compiled on the fly ?

the latter would be great and would fit with the jbpm process versioning scheme... but that might require some hacking with the JspC class from tomcat.

regards, tom.

[kukeltje]

currently they are part of a webapp since you also have to configure faces-config.xml for the mapping. runtime compiling would be great (file a jira issue for this :-P) as would be runtime adaption of the jsf config (there is some info on this in the seam forum, maybe it can be used with another kind of 'injection'.

The reason faces-config is not to bad a choice is that you always have other pages in your application as well, for just some page-flow stuff, separate from the process-flow

I'm therefor thinking of giving the taskBean a session scope so
- multiple taskBeans can be in there, so multiple tasks open will become possible (limitation right now)
- you can have multiple pages with their own backingbean and submit all data in the end (kind of like with wizards)

[kukeltje]

oh... and btw, there is a paged tasklist which will be sortable in a future version

[alkero]

Hello Tom and Ronald,

I think that the monitoring and the administration have functionalities which are common to many projects, and it's slightly different for the user interface, which is often customized.

What about having a dedicated web app only for monitoring and administration purposes, and another one for users tasks, wich will be designed for being easily customized ?

Regards,
David