[Design of JBoss jBPM] - Re: extending form / task functionality
by andyredhead
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... ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979639#3979639
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979639
19 years, 5 months
[Design of JBoss jBPM] - Re: extending form / task functionality
by tom.baeyens@jboss.com
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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979635#3979635
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979635
19 years, 5 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
anonymous wrote : 2) There is an MDB called command listener (cmdlistener) that reads commands from a queue and passes them to the SLSB called command service (cmdservice) for execution.
Yes, I know, as I commented before. But this MDB is only able to read Commands (org.jbpm.command.Command), and however, the objects that the JmsMessageServiceImpl is putting into its queue are Jobs (org.jbpm.job.Job with ExecuteActionJob and ExecuteNodeJob as final classes). So, I'm not sure if the idea is to have another MDB to consume those jobs (replacing the current JobExecutorThread and related servlet), or if perhaps the Commands are thought to replace these jobs. Now, there are two entities: MessageService and CommandService that seems very similar to me. So I would like to know what's the conceptual difference between these two things.
If the jobs and the MessageService are going to be used in the JMS scenario (probably, as we have a JMSMessageServiceImpl), we should need something to consume those jobs, task that is now performed by the JobExecutor and the ServletJobExecutor. I think an MDB is really more suitable into a J2EE and clustered environment.
I don't know if I'm explaining myself clearly. Please, make me know if this sounds confusing for you.
Best regards, and thanks a lot for your comments.
--
Manuel.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979629#3979629
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979629
19 years, 5 months
[Design of JBoss jBPM] - Re: extending form / task functionality
by tom.baeyens@jboss.com
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 ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979624#3979624
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979624
19 years, 5 months