Hi,
I am thinking about using XForms in one of our projects. As the project
is cocoon-based, I had a look at the current developement tree to find
out how XMLForms works and if I could "back port" it to the current
stable release.
It is hard for me to sort things out. Maybe this is because the approach
taken isn't as generic as I excepted it to be. There are quite a few
"special" files to get the wizard example running. Something I wouldn't
have anticipated. Somehow the design seems to be about modifying a
JavaBean instead of modifying the XML model.
What I expected to find in a XMLForms implementation 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).
As I mentioned initially I have not fully understood what has been
implemented in XMLForms until now. If it matches what I have described,
I would be grateful about some hints how to map the steps described
above to files in the cocoon source.
I have, however, the feeling that the approach taken differs from what I
have described. Considering the "wizard" example, I cannot see how the
current approach would allow me to edit some fragment from an XML DB
with XMLForms without additional Java Coding (additional to providing
the fragment as part of the code generated by an XSP and storing it
again). If I'm wrong, again I would be grateful if someone could give me
an example how to achieve this.
If the current approach does not achieve what I have described, would it
be interesting to try to implement the approach described above?
If all this has been discussed previously I apologize. The archives are
currently down and my decision how to continue our project is somewhat
pressing.
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
