[cocampo]

What you guys didn't yet show me is the problem i (or our users) would run into if they didn't separate ui from process logic.

I don't yet see an intrinsic downside of mixing UI with process logic.

I agree that UI and process logic should not be FORCEFULLY TIED together. But i don't see a problem in offering an optional form field in the task that can optionally be used by UI technologies.

This can already cover most situations where there will be 1 UI technology involved for each task form.

Tom, I fully agree with you. You shouldn't have to declare this form field, unless you want it. Also, I think that having the pageflow in another file is better, so you can handle different aspects of your process (yes, I believe UI is also part of a process definition, maybe not in jBPM - yet - but yes in business process modeling in a broad sense, more on this later), and still having a relationship among them.

Regarding complexity, you WILL have complexity in your XML, no matter what you do, if you have a process with, lets say 200+ tasks (including human and computer tasks, as I've seen in the past). So, we can't avoid complexity, but we can think of ways to handle it. Maybe, we should start by defining (or just posting as a Wiki) best practices to handle complexity in large processes, and even think how jBPM and GPD could help to such matter. But a good starting point would be to separate concerns (i.e. process definition and UI, yet they would be related somehow, maybe by a form field as proposed by Tom).

Regarding what (IMHO) could define a business process (in a broad sense, not limited to a BPM technology), I think these elements would be:

- workflows (defined by tasks, roles, applications, artifacts, business rules, business events, business goals)
- disciplines (defined by best practices, techniques, standards, methods)
- guidelines (including templates, procedures - guides for using tools and artifacts, etc.-)

I don't intend this to be an exhaustive list; I think you can't have all of these elements modeled in any BPM tool available. However, I believe you can completely model workflows (as defined before) with JBoss's jBPM/Seam/Rules (maybe with the exception of automatic monitoring of business goals, but that should be a possibe requirement for jBPM BAM or whatever its name will be). Though, I don't know if this would be useful to all of you guys, or perhaps you have a different understanding of business process modeling.

Regards.

[tom.baeyens]

ok. some very interesting views have passed the stage here.

On the basics, i think we are in agreement. jBPM should be mostly concerned with its core expertise: process executions. All other things should be optional.

Such related things are the identity component, the default UI, task management, process analysis and modelling, ...

Let me try and give this discussion the original (limited) focus: Should we add this one String field to the task that serves as a UI task form identifier. This would be a bit similar as the actorId field.

Pro's: every UI technology (amongst which the default one) will be able to use this field to link the task with the form.

Con's: if not used, will this empty field harm performance ?

I'm not trying to settle the fylosophical debates on how and when the UI has to be separated from the core process. IMO, these are similar discussions as 10 years ago: "how OO classes should be modelled". It is important that there is no hard dependency on any UI technology. And secondly, multiple (not all) UI technologies will be able to make use of it. So i see this as a convenience integration point for UI's. Without the need to get to the bottom of the 'taste'-discussion about what should be where... Let's leave that up to our users.

I don't think we should be disabling features to prevent people from making mistakes. Who would have ever created gunpowder in that kind of reasoning ? We have to explain good practices and tradeoffs in the docs and with sensible defaults. IMO, not by removing optional integration features.

[andyredhead]

Ok, fair enough.

I shall defer "gracefully" ;)

A single string value that can be used by any gui shouldn't really do any harm.

[cocampo]

Ok, I also agree on the basics.

Though, there is one question left: how to tie users/roles and pageflows?. Should be this handled separately, is this a matter of a JAAS-like library or what?

Regards.

[kukeltje]

regarding pageflows:

- the 'page resolver' first resolves to pages in the database (processdefinition)
- if none is found, assumes it is relative (or absolute if prefixed by a /) to the webcontext the post was comming from
- this latter can be the start of a default jsf pageflow as is possible now

(or seam pageflow, or whatever)

[crossleyjuan]

I have the opportunity to see another BPM solution and that solution had a lot of troubles combining form information in the workflow, just because that is not the place to put any UI related information. I'm new in this discussion forum but I think that the BPM works as a simple MVC pattern, where the BPM core is primary the Controller, the Webapp is the UI and finally the Model is the actual attribute mechanism.

What will happen if you put form information in the task node, and the user decides to use a cell phone, or PDA instead of a web browser?.

I'm studying right now the form.xml to add more information, and to propouse something that solves this problem, I just wanted to put my opinion in here and get some feedback from you.

[tom.baeyens]

crossleyjuan: i agree with you, a process can be seen as the controller in the MVC pattern.

in my proposal, the process contains a tech neutral form identifier. the process execution doesn't do anything with the form identifier. Every UI technology is free to use the form identifier as it sees appropriate.

the benefit is that you get a more compact notation in simple scenarios. also, this approach covers most use cases. in case each UI can live with the same form identifier (and it's own way of resolving this name to a specific form), this would cover most use cases imho. in case you want multiple different form identifiers per task, you can always introduce a forms.xml at that time.

...all this not to prove you wrong. on the contrary: to inform you of the previous discussions and reasonings on this topic so that you can think along.