[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-2166: ----------------------------------- can anyone with schema knowledge paste the right piece of schema to be added to all jpdl elements so that the language becomes extensible ? i'm looking for the proper usage of the any and anyAttributes. the goal is that elements and attributes can be added in any namespace (also the jpdl namespace) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Tom Baeyens updated JBPM-2166: ------------------------------ Fix Version/s: jBPM 4.0.0.GA (was: jBPM 4.0.0.CR1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Tom Baeyens updated JBPM-2166: ------------------------------ Fix Version/s: jBPM 4.1 (was: jBPM 4.0) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Sebastian Schneider commented on JBPM-2166: ------------------------------------------- Are you already working on this? If I got it right, the schema should be extended in that way, that you can add additional elements like for example customized task-elements and additional attributes to existing elements while validation through the schema still works? Might be helpful: http://www.w3schools.com/schema/schema_complex_anyattribute.asp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Gregg Freeman commented on JBPM-2166: ------------------------------------- What if there were a different approach? I feel like the available node set is adequate, with the existing custom node. The "killer" feature that's missing is the ability to enhance or replace the existing node behavior. So, what do you think about optionally allowing an activity behavior chain? Any activity could specify a list of ActivityBehavior implementations that would be executed on activity start. Additionally, we could specify 2 additional flags: include-default-behavior and default-behavior-location. The attribute include-default-behavior would specify to include the default (a boolean attribute), pre-implemented behavior in the node execution and would default to true if not specified. The attribute default-behavior-location is a enumerated attribute of "first" or "last" and would specify where in the chain the default behavior would be executed. It would be defaulted to "first" if not specified. ActcivityBehavior would be enhanced to return a boolean from the execute(ActivityExecution) method and would indicate if processing in the chain should continue. All of the default implementations would return "true", indicating the execution chain should continue. A return value of "false" would indicate that no further processing should continue. This would allow custom behavior to do things like conditionally create tasks in the task node, or notify task candidates after the task has been created. It could open up a bunch of possibilities... I'll upload an example xml file of what I've described. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Ronald van Kuijk commented on JBPM-2166: ---------------------------------------- Gregg, In my humble opinion this makes things to complicated. On the one hand you say the nodeset (which includes implementation aka behaviour) is sufficient but you want it extensible. jPDL itself is extensible in a different way. See the jbpm.jpdl.bindings.xml file in the source. Implementing new activities (and overriding) existing ones is possible that way. Using additional behaviours (in a way like interceptors?) like you propose is imo not needed, also because it still is the intention to have the task behaviour be a 'mini process' in itself (see jbpm.task.lifecycle.xml in the pvm module source). So instead I would enhance the task behaviour etc with things that are valid usecases. That way *anyone* can benefit.... This specific issue is therefore not specifically meant to make the workflow, but to add properties etc to e.g. a task (like avg-duration etc) that you can use when accessing the task via the api (like task.getProperty('avg-duration') and other things. But I admit that this is partly my personal interpretation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2166?page=com.atlassian.jira.plug... ] Gregg Freeman commented on JBPM-2166: ------------------------------------- Sure someone can add their own binding, but at this point, it breaks the graphical editor (at this time). The problem with the custom node is that there is zero thought for reuse of out-of-the box functionality. If I want to override existing task functionality, the only way to do it using the "approved" API is to completely rewrite/re-implement the existing Task behavior. One can easily do this by inheritance / delegation in custom code, and you get the same capability with an interceptor model as well. Seems like an easy way to add a _bunch_ more flexibility if people need it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBPM-2166?page=com.atlassian.jira.plugin.sy... ] John Graham updated JBPM-2166: ------------------------------ Assignee: (was: Tom Baeyens) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira