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...