guys, that's quiet contradictory to what say on the forums. the page states "jBpm is an open-source workflow initiative that acknowledges the work on patterns.", but whenever that discussion regarding patterns has been put on the plate most of you tried to explain me why we don't need patterns and that "real" users never "asked for that". What's up? /Heiko On Thu, 2008-10-23 at 08:22 +0200, Bernd Rücker wrote:

Tom Baeyens schreef: It sais that on the front-page as well, which is clearly more up to data. Most likely manual stuff, no CMS +1 It was to for me (e.g. how the assignment to different actors for the Multiple Instances with a Priori Design-Time Knowledge <http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp13.... is left in the dark, but when lookin a little more detailed at the data and resource patters (talking about vage... some of those are more vage than the original controlpatterns) the console of a BPM is seen as an integral part of the system (see Cancel Task <http://www.workflowpatterns.com/patterns/control/cancellation/wcp19.php>) funny... And Tom is right, the ui-stuff (or any interface) needed for a lot of those patterns is left in the dark (see my blog entry on milestones again where I already mention this) The controlflow patterns have been made more clear, the others not (yet), but they have a group on google <http://groups.google.com/group/workflow-patterns/> now where we can participate more openly in discussing the vagueness or our implementations/proposal Already working on it s, privately , since I want to write a blog entry on it, so do not expect to much to soon. In some cases it is fairly simple to support more patterns in language constructs (e.g. the NOutOfM join) by making one field that is already in the node implementation persistent, add it to the xsd as optional and parse it in the JpdlXmlReader Exactely. We've never been against the patterns (that's why we "acknowledge the work on patterns"), it's more a differenct view in how they should be supported. e.g. flexibility with some (reusable) javacode or strict language constructs. I'm currently thinking on how we can combine the two without having to extend the schema (xsd and db) each time. That is one of the items of my blogentry (Hmmm..... this jBPM thing is costing me more and more of my free-as-in-beer time.... ;-)) I'm thinking along the line of pre-packaged actionhandlers which you do not have to include in the processdefinition(where you can 'ref-id' them, BUT you should be able to override param values from the location they are used (currently you cannot do this, only params in the declaration are used, so globally) Btw, I'd like to add a column on http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMSupportedPatterns vor 3.2/3.3 but also see http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMPatterns. This latter is a more textual page, but imo does not add that much info (besides the "intro's") Any proposal to combine those? Ronald