Two additional comments/questions. First, my original question remains: why does the XForms processor (or other step?) "clobber" data in an XForms instance document not explicitly collected by an XForms input widget on a given screen? We may not need this question answered to implement a multi-screen wizard now that you've provided an alternative, but something in the future may require it, so if there is an answer, we'd love to know.
As you may have noticed, the XForms elements (like <xforms:input ref="/form/firstname"/>) are converted to HTML elements with a name set to an XPath expression. This is an "implementation detail", but maybe helps better understand how the XForms processing works. When the form is submitted, you will have on the URL (or in the posted parameters): /form/firstname=John. The XForms Input processor (see http://www.orbeon.com/oxf/doc/processors-xforms#N1014D) creates the XForms instance based on the request parameters and the XForms model. So to answer your first question: the XForms Input processor only puts in the instance data that comes from XForms controls, including <xxforms:hidden>.
The second comment is a more general one: how are OXF users supposed to know about all these great "hidden" features, such as the one you just exposed where a <result/> can process an xupdate document right in the controller file? Unless we missed it in the other examples, we had no idea <result/> elements could take parameter documents!
The fact that the <result> element can contain XUpdate instructions is documented in the Web Application Controller documentation (http://www.orbeon.com/oxf/doc/processors-controller). The Excel export example uses this feature, in addition to the XForms Wizard example that was just added. But I grant you that the documentation could be more extensive on the subject :).
Alex
_______________________________________________ oxf-users mailing list [EMAIL PROTECTED] http://mail.orbeon.com/mailman/listinfo/oxf-users
