JBossDeveloper

Regarding the "one file", do you want me to continue in this subject, or should I open another thread?

Regards.

so you're arguing that the forms.xml mapping file should disappear, right ?

that can be considered. i'll think about it.

anyone else got an opinion ?

i think i initially created a separate forms.xml to avoid that the task definition gets an extra column in the database.

but now i don't think this is important. so we probably will go to moving the task form reference to the task in the processdefinition.xml.

this will impact the designer so we will have to carefully coordinate such a change. koen, how hard would this be for you (the update and verifying if/how this could break compatibility) ?

xhtml files in the webapp i think is already possible but i'm not sure. David, do you know that ?

i think it could be possible to support both xhtml and jsp files. the taskForm field of the task could become something like this: The webapp could look at the extension and based on that redirect to a separate jsp or include the xhtml into a template form page as is done now.

let me know where this doesn't make sense cause i had to write this fast because koen is waiting for me to get a sandwish :-)

Sorry to barge in at such a late stage, however I think that putting GUI specific information into the process definition xml is a mistake.

There are many options for building an application presentation layer, some of which would make no use whatsoever of a form definition held in the process definition (one of the projects I'm working on at the moment has an applet client).

I think that the core jBPM engine should provide interfaces for allowing access to context variables and the state of tasks (which it already does).

Going beyond that is starting to mix concerns between presentation and flow control...

So adding the form definitions might be nice for a perticular project but will be (at best) unnecessary clutter for many others...

there would be no logic behind the taskform field in the task. i think it could make sense that the task has a field called taskform, which is used and interpreted by external tools like our webapp.

so the task only gets one extra field which is optional and doesn't impact runtime execution.

wether mixing flow control with presentation is a good think depends on the use case, i think. in some cases it is easier to define it all in one file, sometimes it is easier to separate things.

isn't this just style and taste versus good or bad ?

if that is the case, then i am in favour of supporting both. as long as the runtime performance is not impacted. in this case the impact is minimal. by default, hibernate will load all null values in the taskform in case it is not used. not sure if that is a problem. if it would be a problem, the hibernate mapping for the taskform field can always be commented...

what do you think: is it a matter of taste or a matter of good or bad ?

I will agree that if things can co-exist without impacting each other then fair enough (give people the rope to hang themselves).

As a general "rule of thumb", I find that whenever concerns that could be kept seperate are brought together, the result is painful maintainance. Sometimes it is inevitable that if the process changes, the GUI needs to change or vice versa, so the maintainance is all tied together (and you have to accept the pain) - sometimes it doesn't.

A more sensible objection in the short term is that the GPD will be broken for a while because a tool that is to do with designing flow will have to be adjusted to accomodate GUI stuff.

Cheers,

Andy

Well adding an additional attribute on the task is not that difficult a thing to add. And if it is optional, I am quite sure this will not break compatibility.
Whether adding the info to the database is a matter of taste or a matter of good and bad, I am personally more in doubt. I would opt for the mapping in a forms.xml file as it exists today because it isolates the processdefinition from the front end technology...

Regards,
Koen

"koen.aers@jboss.com" wrote:
I would opt for the mapping in a forms.xml file as it exists today because it isolates the processdefinition from the front end technology...

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.

On the other hand, i DO see an intrinsic problem with the current approach. Namely that users have to maintain the indirection manually in the forms.xml. (The GPD could improve support for this, but there is always the chance of a user modifying the task name with a text editor). Removing that indirection also removes the possiblity of errors in that indirection

At the moment, the process definition xml contains infomation about the process.

The more different kinds of things you put into that file, the harder it becomes to understand that file and the more likely you are to put people off from ever using jBPM.

So, at the moment you'd like to add some extra bits for a perticular kind of GUI. Maybe next week someone else comes along and wants to put some extra information in for something else (synchronising multiple process instances perhaps, as a non-GUI example) and the week after its adding something else... all the while the process definition becomes more complicated.

Meanwhile, people who are using the workflow parts of jBPM and not all these other bits look on in horror as it all gets more and more complicated...

Maybe I've got a slightly skewed perspective at the moment - the two projects I'm working on at the moment that have a significant jBPM component have fairly non-standard GUI requirements:

1) A microsoft ASP frontend that interacts with an EJB3 middle tier using web-services (the EJBs interact with jBPM)

2) An applet sitting in an intranet environment.

I bring these up as examples of happily using jBPM without expecting jBPM to do the GUI work. Neither will benefit from further complicating the process definition file.

If there are issues with building GUI stuff using a certain approach, the issues should be solved at the GUI end, not the jBPM end... ?

"andyredhead" wrote:
At the moment, the process definition xml contains infomation about the process.

The more different kinds of things you put into that file, the harder it becomes to understand that file and the more likely you are to put people off from ever using jBPM.

"david.lloyd@jboss.com" wrote:

I disagree. People who don't want the added features, won't use them. And I think the general expectation is that people will use the GPD for building jpdl processes, so they probably won't see the XML at all anyway. Designing an XML document to be human-readable is, at best, an exercise in futility.