cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: XMLForm / instance data from XML / Popup sample
Date Sat, 11 Jan 2003 15:38:20 GMT

----- Original Message -----
From: "Christian Haul" <haul@dvs1.informatik.tu-darmstadt.de>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, January 10, 2003 4:43 AM
Subject: Re: XMLForm / instance data from XML / Popup sample

...

> > I can see how you might use another source for the document and not need
the
> > XMLFormTransformer at all.
>
> Mmmh, doesn't the XMLFormTransformer do the XForms -> HTML conversion
> i.e. fill in all the values and handle repeat elements &c.?

Yes and no. It converts from XForms to XForms, whicle filling in all the
values.
After that XSLT is used to convert from XForms to HTML.

>
> > Let me clarify the scenario though:
> >
> > 1) Say you have a document extracted from ESQL
> > 2) You also have an XForms document which refers to elements in the
document
> > 3) Now, who will be responsible for resolving the references to 1) in 2)
>
> Since XMLForms operates via the model through XPaths, I think of 3a)
> extract the instance data to a DOM and 3b) have the XMLFormTransformer
> use that instead of a Form.

Oh, I understand.
The Form actually is just a wrapper. It holds to a data model, which can be
JavaBean or DOM. So if you create a Form shell and stick the DOM in question
in it,
then the rest should work fine. Actually, to be precise the DOM should be
wrapped in a DocumentContainer,
so that JXPath can correctly detect its type. Given the form id and the
source for the model in the
sitemap config, creating the wrappers can happen automatically.
http://jakarta.apache.org/commons/jxpath/users-guide.html#Containers

>
> > 4) Then, when the browser posts the HTML form, what component will
update
> > the underlying data model (SQL database for example)?
>
> This is optional. XForms can be used for display only. Another
> possibility is to create an XML document from the parameters and store
> just that.

This is good. JXPath has a feature which is not currently employed by the
XMLFormAction.
If the underlying model is DOM and the option "create nodes if reference not
found"
is turned on (I forgot the exact details), then you can use the
XMLFormAction to do the work
in both cases (fill in vs create doc).

>
> One application is to store the entered data in a database (XML
> database or a CLOB column in a RDBMS), store the form to enter, edit
> and display that data in another database (other table).
>
> Another reason for the request to loose the coupling between the
> XForms to HTML conversion and the XMLForms framework is to be able to
> experiment with other backends. Certainly, this, XForms -> HTML, is
> needed with all approaches. But validation, processing esp. in
> relation to flow script is still discussed.

Validation is optional as it is now. If you do not provide validation
sitemap parameter,
validation will be skipped.

If you mean that flow logic and backend communication should be allowed
outside of an action,
then maybe the route is to make the AbstractXMLFormAction a concrete class
which can handle more sitemap parameters and provides default behavior for
the possible inputs.



Ivelin




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message