[jboss-dev-forums] [Design of JBoss jBPM] - Re: Potential enhancement to jbpm

[brittm]

anonymous wrote : alternatively users should be able to write their own parsers to extract the information from a process archive and put that information somewhere in the process definition. 
While cutomizing the core jBPM libraries and data model is always an option for virtually any problem, its never the preferred solution for common problems.  --the more frequently users must solve common problems in this way, the more likely they are to look elsewhere or to fork the project.

anonymous wrote : In jPDL 4 i want to add annotations. Basically, annotations are key-value pairs that you can associate to all process elements. 
This does allow the user to solve the problem much more easily, and is a big improvement over what we have now.  However, it falls short of providing a standard solution to the nearly universal problem of declaring an interface requirement.  It's also not an option till version 4. :-)

Allowing the user a way to solve this problem is just a start, but providing a common solution is what is really needed.  The user shouldn't have to look at an attribute tag and then invent a way to use it.  At least for this particular problem which is such a common requirement, the jpdl should acknowledge the issue and provide the solution.  At the same time, the jpdl should only solve it from the process definition side--in a way that does not tie the definition to a display technology.

The basic solution I presented earlier in the thread does all these things.  The solution:
1) presents users with a common, defined jpdl solution for associating elements with UI requirements.  
2) is not specific to any display technology, whether it be Swing, JSF, or any other tech that comes along.  
3) does not require any knowledge of the display technology.  So the display technology can be changed on top of existing definitions without impact.
4) can be added to jBPM 3.3 with minimal effort.
5) could likely be used in the jbpm web module to support robust UI versioning with minimal effort.

Items 2 and 3 are true so long as the user uses a reference to a UI requirement, rather than an actual view id; however, there is nothing stopping them from supplying a view id and using it directly if they don't mind tying the definition to their display technology. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126767#4126767

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126767