&quot;tom.baeyens(a)jboss.com&quot; wrote : Using EL to access variables is a good thing (maybe they already are included in the lookup). But you should take into account that users can define variable names with spaces. In that case we need another lookup mechanism. Ok, in that case probably it's more appropriate to say: <h:inputText value="#{var['payment ID']}"/> &quot;tom.baeyens(a)jboss.com&quot; wrote : Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies. But requiring certain beans to be present is a nuicance. I don't want the task forms to be expecting certain managed beans, because this restricts my ability to make changes. &quot;tom.baeyens(a)jboss.com&quot; wrote : We should avoid that people have to learn the jBPM Form Layer apart from JSF and Facelets. At least, this was the idea when designing the forms solution. I wouldn't want to create a vastly new syntax or anything. But generally speaking, using a variety of component libraries is a very normal pratice that Facelets users are used to. It makes perfect sense to provide a component library for dealing with task forms; it's the most natural integration with Facelets in my opinion. &quot;tom.baeyens(a)jboss.com&quot; wrote : Also with the buttons, the idea was that the graphical designer will generate those. After initial generation of the form by the gpd, the users now are able to customize the boring form layout to their own wishes. I still maintain that some type of custom component is needed here. Better that the user could say: <tf:button transition="to receive payments" .../> ...but still be able to specify all the standard JSF button attributes as well, including images, ID, styleClass, etc. &quot;tom.baeyens(a)jboss.com&quot; wrote : By just using plain JSF/Facelets constructs, it seems much more flexible for users to start tweaking the graphical form. I agree. &quot;tom.baeyens(a)jboss.com&quot; wrote : On the other hand, if users don't customize the forms, they can always re-generate after they made some updates that have an impact on the form. | | So this explains why I was not too concerned with usability of the form constructs. My main concern was lowering the learning curve. The other important thought is that mostly, users will generate the forms and will not be looking at the form code. With the form designer generating the inital form, I don't think usability will be a problem at all. If the user gets "lost" they can always just regenerate. In which case, the next most significant concern is implementation. I don't want to be in a situation where we've painted ourselves into a corner, just because it was a convenient first pass of an implementation. At the very least, I want to remove the usage of "taskBean" from the generated forms completely, and also I want to remove anything having to do with page navigation (in this case, action="" on the buttons). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983923#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...