Hi Erik,
Le vendredi 17 d�cembre 2004 � 18:37 +0100, Erik Bruchez a �crit :
> 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.
Yes, that's the next thing I need to try!
> 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.
The thing I don't like very much about this solution is probably more
aesthetic then technical...
In my simple example, the XForms is written has it would have been
written for any other implementation (except for the need to separate
the model from the UI which isn't a bad practice anyway).
In the BizDoc example, that's no longer the case since you had to embed
the actual instance document into a container (ie the root element
"form") together with the actions that are needed in the client server
communication between the browser and the server.
The consequence of this adaptation is that your instance document isn't
any longer the document that you are editing and that you need to
carefully craft your pipelines (using xupdate in that case) to embed and
desembed the actual document into the instance manipulated by the
XForms.
Is there a way to avoid that or is it a consequence of the architecture?
Thanks,
Eric
--
Lisez-moi sur XMLfr.
http://xmlfr.org/index/person/eric+van+der+vlist/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
-------------------------------------------------------
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
