anonymous wrote : I'm not sure how useful an EL would be for setting restriction. By returning a boolean true or false for displaying it or not anonymous wrote : | I'd need some kind of UI identification switch or the user's roles in scope to compare with. (Would SEAM make these things more readily available to the process execution?) (Or have I missed some funtionality that allows container roles to be pulled into the execution context?) Seam: yes, or an extension in jbpm. anonymous wrote : Some things to consider: | * This is a big organization. We have an LDAP infrasfructure for managing users and groups--jBPM's identity component is not an option. | I think this would be a typical scenario in most enterprises. Same here.... shall we both work on an ldap identity component? anonymous wrote : * Our UI is already built and extends far beyond what can be generated by the GPD (and probably will for a very long time). Same here... GPD based generated forms is nice in some cases, not others. Therefor I want the processdefinition to be namespace aware. That way you can add elements/attributes to the pd and e.g. use an xslt to generate jsf forms (or something else) anonymous wrote : Not to mention, that when regularly using all of jpdl's capabilities the current GPD becomes more of a hinderance than a help. (Ok, I confess it's been a while since I've looked at it :-) | For the forms that is currently true... dropdowns, selectitems etc... ever looked at xforms? anonymous wrote : * Bernd, we have scores of tasks that are managed by our system but that are not yet performed in our system, if they ever will be. That means no custom screens (and no additional configurations) are created for over 100 tasks--users just claim a task and take an available transition. This scenario is typical for a large company that is implementing a workflow system to manage process flows across several existing IT systems. Requiring the UI to have proper configuration for every item is a significant barrier to entry when it comes to getting lots of processes and tasks on the system in a relatively short amount of time. No comment (I simply have none ;-)) anonymous wrote : I'm really not trying to push a particular solution, but I am trying to point out an area of pain--an area in which a few small compromises (or as yet unseen solutions) could go a LONG way toward helping the largest corporations see a rapid deployment and return on investment. Once the existing processes have been defined, it comes down to this: I can set a few flags and deploy processes acoss the entire company under a generic UI, or the company can wait until I've mapped over and built up a UI for 200 tasks. In our case, we've had to hack the first solution, because there is no way the company would have let us do the latter one. What about the namespace extensions? The GPD should leave those alone .... that would help a lot.... (in our case) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053660#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...