[jbpm-dev] [Design of JBoss jBPM] - approach to new forms

Thanks for the initial discussion. I have a more clear picture now on the position of you guys, but still have a some questions idea's therefor some statements (sometimes a summary of the discussion) on which I hope you can comment. jBPM 3 forms solution is not sufficient for (at least) several reasons (not al mine, sometimes customers, sometimes a console thing) - typing is not taken into account (e.g. no datepicker out of the box) - complex forms not supported (nested elements) - cannot be (easly) used outside of the console The jBPM forms solution also has an advantage: - a simple RAD type demo can be done showing a full process with (simple) forms - forms can be customized afterwards to at least a certain extend Console thing: - look and feel customization is limited (logo, colours, big customer issue, where big mainly refers to customer and not (specifically) the issue) Now the question for me which problems do we want to solve and when. Do we want to go the whole 9,1140 meters in the 1st down ( , is decimal separator :-) ) or do we take it in smaller steps. Statistics show not going al the way has a higher success rate. Now why do I state this. There were 3 approaches to the current console 1) It is the holy grail (nirvana if you are into bhuddism), I want to (ab)use it and extend it as much as possible 2) it's nice for RAD, nothing more and forms can be customized to a certain extend little 3) Not use it only for deployment and overviews. My opinion: 1) People using like this were either crazy (personal opinion), had different experience with other bpms or just had different expectations, or limited knowledge of frameworks 2) Not a bad choice, did that to once or twice 3) Most likely what sensible people did (me to) but there I developed a framework which made it possible to do RAD, just with a custom webapp (combined with custom look and feel) Why would people go for 1? - Out of the box usage - they did/do not have java developers Problems: - no easy access to own datasources etc - repackaging for using own beans etc - you need java delvelopers Why did people go for 3? - They had a different inhouse technology (e.g. struts) - They could not easily re-use the forms solution (including tasklists) or they did and we (ok mainly you JBoss guys) did not know Problems: - you need java developers Now I personally think that the forms solution should eventuallly comprise several things a) Good and stable api for taskmanagement b) Tasklist functionality (not reassignment etc) c) Basic forms functionality (little more complex then there now is), e.g. datepickers, but not repeatable items(complex types) etc d) editor/designer support for c) e) Complex forms functionality f) Designer support for e) g) Reusable components, preferably to a large extend independent of the rest of the ui technology But I'd spread this over 3 iterations (assuming 8 weeks release cycles) and 4.1 being after 4.0.1 1) 4.0.0.GA: a, b, c, d 2) 4.0.1: e, f 3) 4.1: g Now if you look at the amount of work that still needs to be done, not only for the forms, but in general, and at the same time keeping in mind that backwards compatibility for the existing forms should be supporterd (it should shouldn't it?), I'd take the following approach: Whatever forms solution is used, it is not a bad thing to go for handling forms in iframes. This way, it should not be to difficult to leverage the existing forms functionality without the existing console. They could be run in the new console with some slight adaptations in the backend of the formshandling I'd think. At the same time it could be deprected so to make clear it will not supported in 5 anymore. This buys a little more time to get the new forms solution up and running (it does not have to be ready for 4.0.0.GA, only demonstrable (? stupid word)) and in the mean time, announce it, describe it, look at conversion of the existing variable definition to the new one (should not be that difficult). Personally there is only one option for this. XForms since much of it will be in html5/xhtml2, lots of other vendors support it (IBM, Intalio, SAP, Nuxeo, Alfresco, Orbeon To summarize: Advantages of this approach: - backwards compatibility is met - initial improvements are there - time is bought to focus on delivering at july 1st with a quality release - jBPM enhanced forms handling can be announced, technology wise - a conversion of the current variable definition to a new one is possible any comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215420#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...