----- Original Message ----- From: "Christian Haul" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
