But this wasn't the real question: why XForms at all? Why use a client-side spec to constrain it in a server where it doesn't fit?
OK, here's the motivation. We have built a workflow engine (http://wfmopen.sourceforge.net) that uses an XML based workflow description language (XPDL).
Part of the definiton of a workflow is (better: may be) that a specific activity is to be executed by a human. And there again it may be that the action consists of providing some data, maybe based on the display of other data. So the activity is implemented as a call to a tool that displays some data in a form, lets the user edit or input some more data and returns the result to the workflow engine.
Of course, we do not want to build a tool for every form. Rather we want to have one generic tool that can take the form description as a parameter. And we want to embed the form description in the workflow description as part of the tool definition.
And here is where XForms fits 100%. We simply use the (X)HTML with XForms UI-elements for the form as one of the parameters in the tool definition (i.e. you define a tool by combining the one generic implementation class with a specific HTML fragment). Into the HTML, the tool - when called - inserts the actual data and OUT parameters as a XForms model and then hands this to the XForms processor (at least that's the targeted scenario). Currently, we have a very, very small subset of the functionallity by simply applying a stylesheet with non-standard dynamic evaluations (to resolve the references to the model elements) to the mixture of HTML, XForms UI elements and XForms model, thus producing a displayable HTML form.
So, I do not favour XForms in particular. But it is the only starting point that I have found that supports this scenario with runtime form definition. Maybe I have simply not understood XMLForms in Cocoon, but I have tried. And I am sure to have understood that you need JavaBeans corresponding to your forms and this rules out XMLForms for our scenario, because we must be able to create the form completely at run time (from the workflow description). And though maybe possible, I do not want to do something with dynamic code generation (for the JavaBeans), I need a fully interpreted solution for form creation.
OK, this was a fast walkthrough and I hope I have made the problem clear. If you know of another approach to this, I would, of course, like to know about it.
- Michael
