Another Aproach to Cocoon XForms

What I expected to find in an XMLForms implementation for Cocoon was about this:

1. Some generator produces XML that includes one or more XForms models and XForms UI elements. (The instance data in the model may have been derived from a JavaBean, but could also be taken from another source, such as an XML DB.)
2. An XForms initial-transformer reads this XML. It extracts the XForms:model, builds a DOM tree and triggers the initialization events. It saves the received SAX events (minus the XForms model) and the DOM tree that represents the initialized model as session attributes with names that reflect the original request.
3. An XForms layout-transformer receives the XML. It evalutes conditional XForms elements such as the "switch" element using the model DOM tree from the session context and "prepares" the XForm Controls by resolving the references to the model data and providing the data to be displayed as some kind of XForm Control extension (so we need no "xalan:evaluate" in XSLT later).
4. A simple stylesheet transformation maps the "extended" (i.e. references to model data resolved) XForms Controls to e.g. HTML. All created links or actions include a (hidden) parameter that reflects the original request and point to the generator described in (5).
5. An XForms generator processes the user input (provided as request parameters). It applies the input to the model DOM tree found in the session context by updating the model instance data and triggering events (of course we cannot generate all events such as focus related events). This includes any required validation. If the action includes the final submit and validation is OK, it "redirects" the request to the xforms:submission (this target [maybe the same as the generator in (1)] is responsible for updating the originating JavaBean or storing the data in an XML DB etc.). Else it simply re-emits the events saved in (2) and processing continues with the transformation described in step (3). Saving the SAX events in (2) is necessary as the output generated in (1) may result from a post, i.e. we cannot generally call the generator described in (1) again (saving should be more efficient anyway).

When I looked at the implementation currently under development within the Coccon project, I could not identify this approach.

I do not claim to have fully understood the approach taken by the Cocoon team, but from what I have understood, I got the strong impression that it is not as comprehensive as is required by the project that made me look at XForms in the first place.

So I decided to give the approach outlined above a try.