cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Lipp" <michael.l...@danet.de>
Subject Re: Server-side XForms (was Re: Disappointed about avalon usage)
Date Wed, 01 Oct 2003 12:07:01 GMT
> 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



Mime
View raw message