[Design of JBoss jBPM] - approach to new forms
by kukeltje
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#4215420
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215420
15 years, 3 months
example with businessmessages
by Ronald van Kuijk
example of using businessmessages (also in task forms since the xxform is
based on the same xsd)
15 years, 3 months
I go on vacations
by Bernd Rücker
Hi all together!
Just wanted to inform you I go on vacation on Thursday for 4 weeks. I will
travel through Mexico with backpack, so I will resist to look into my
mails or anything J
I am already curious about how jbpm 4 looks like when I return!
Until then I wish you happy coding
Cheers
Bernd
EJB-3-Buch: <http://www.ejbbuch.de/> http://www.ejbbuch.de/
Unsere Seminare: <http://www.camunda.com/seminare/>
http://www.camunda.com/seminare/
Blog: <http://www.bpm-guide.de/> www.bpm-guide.de
---------------------------------------------
camunda services GmbH - The Business Process Company
Werastraße 18 - 70182 Stuttgart
<http://www.camunda.com/> www.camunda.com - <mailto:info@camunda.com>
info(a)camunda.com
---------------------------------------------
Bernd Rücker
Geschäftsführer
Telefon +49 711 3278645
Mobil +49 171 1473461
<mailto:bernd.ruecker@camunda.com> bernd.ruecker(a)camunda.com
---------------------------------------------
Amtsgericht Charlottenburg: HRB 113230 B
Geschäftsführer: Jakob Freund, Bernd Rücker
---------------------------------------------
15 years, 4 months
gpd-3.1.7
by Thomas Diesler
Hi Koen,
could you please resolve your issues if they are done. Otherwise could
you please tell us what this is waiting for.
cheers
-thomas
15 years, 4 months
