Eric van der Vlist wrote:
> I have re-read it carefully and that's much clearer by now. > > The simplest page flow I can think of to follow these principles is: > > <page path-info=".*/xform" matcher="oxf:perl5-matcher" > xforms="form.xml" model="read.xpl" view="view-form.xsl"> > <action when ="normalize-space(/*) != ''" > action ="write.xpl" /> > </page> > > In that example: > > * form.xml is a static XForms model with an empty instance. > * read.xpl is a pipeline that reads the instance from the file > (connecting the data output of the identity processor to the > instance output). > * "normalize-space(/*) != ''" checks if the document submitted by > the form is empty or not. > * write.xpl saves its "instance" input to the file > > Would you say that this is cleaner and more conform to the page flow > architecture than my previous attempt?
This would work. It implements a simple read / write scenario. Now, what can happen is that on that page, you may want to perform other actions, or XForms may submit the form to perform things such as adding lines with xforms:repeat. In such cases, you would have to be careful, in your page model, not to re-read the document from the database, but to just pass through the instance received. This can be done easily with a p:when in your page model.
Another way of doing things is illustrated by the BizDoc example. It
works with two pages: the first one ("Summary" page) for document
selection, and the second one ("Detail" page) (in this case actually
split over two pages, but that is a detail) for editing and saving the
document.The Summary page lists existing documents, and when a "View" button is pressed, runs an action (still associated with the first page) that does the retrieval from the database. Then, in the page flow, the retrieved document, returned by the action, is passed to the Detail page by updating that page's XForms instance. The Detail page does not need a model.
Saving is done with an action associated with the Detail page. Here you are testing that the document is not empty, which is fine. The BizDoc example does slightly more complex testing, to make sure that you are not saving a form that is not valid. So it does:
<action when="/form/action = 'save'
and not(/form/document//[EMAIL PROTECTED]:valid = 'false'
and not(ancestor-or-self::[EMAIL PROTECTED]:relevant = 'false'])])"
action="detail/save-document-action.xpl">
<!-- Actually save the document -->A second <action> element detects the case where the document is invalid, and stores some state reflecting the situation in the XForms instance.
-Erik
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
