October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

I wouldn't worry. If we support this approach and associated use case then it'll be in 2007 and not the release we have planned for this year. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979645#3979645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979645

19 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by kukeltje

If we keep it a separate file, I would opt for the format of pageflow.xml. The difference is not that big (imo) to justify another format (IMAO ;-) ) In addition it is a first step to allow wizard like functionality out of the box. Correct? If we keep seperate files, I would like to have either a 'validate' option that tests if there is a form defined for each task IF there is a forms/pageflow.xml available. Another one of my pet topics (stokpaardje in Dutch) is the variable type. Is that in the pd (since it is not about front-end technology) or just in the forms? I'm updating my cvs with all build changes so I can check in some of my webservice thi ngs and check the additions to the webapp, designer etc... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979633#3979633 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979633

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by andyredhead

"koen.aers(a)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... | Koen has managed to distill my argument down to a single sentance :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979632#3979632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979632

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by koen.aers＠jboss.com

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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979631#3979631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979631

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by andyredhead

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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979630#3979630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979630

19 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by andyredhead

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... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979621#3979621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979621

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006