Hi Erik,
Le jeudi 16 d�cembre 2004 � 12:24 +0100, Erik Bruchez a �crit :
> > The flow to edit a document is thus:
> >
> > * initialise the model with the current document in the pipeline
> > referred by the "xforms" attribute of the page definition.
>
> Using a pipeline to generate the XForms model should be used only when
> your model *must* be generated dynamically. I elaborate below.
>
> It is important to realize that the model includes not only the
> skeleton of the instance with its default values, but also, and maybe
> even more importantly, references to schemas, and bind elements for
> calculations and validation.
>
> Now an XForms model, whether static (XML file) or dynamic (in
> Presentation Server generated by a pipeline), is currently the only
> place where you can specify all of this, *except* for the XForms
> instance itself: because it is so important to be able to manipulate
> an XForms instance, Presentation Server gives you direct access to it
> in its Page Flow pipelines, and allows you to pass or update XForms
> instances between pages. This way instances can be created, modified,
> and updated without making any changes to the XForms model.
Hmmm... I had missed the fact that the model pipeline could be used to
initialise the instance!
> So the bottom line is that if what you want to do is just edit
> instances of XML documents that conform to a certain schema, and that
> those documents are retrieved from some kind of persistent store, you
> don't need to generate a dynamic XForms model. You can just produce
> the instance in your page model pipeline, or generate it from an
> action pipeline in a page and pass it to another page with the PFC.
>
> > * save the instance model as the updated document in the pipeline
> > referred by the "model" or "view" attribute.
>
> Typically, you would do this in an action pipeline, which directly
> receives the XForms instance, rather than a model pipeline.
OK.
> This is really the typical XForms scenario by the way. The BizDoc
> example (supported by the tutorial) is showing (at least that was the
> hope!) how easy and elegant it is to combine XForms, Page Flow and
> pipelines to achieve all this.
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?
> Now if you are *really* trying to generate different models, for
> example because you have an external definition of your form, which
> requires producing more than just an instance, then you will want to
> use a pipeline to generate the entire model. But this should be the 1%
> of cases.
Probably the most promising, though :-) ...
> One reason for this is that in most scenarios I can imagine, you
> wouldn't create a model based on nothing: you would want to configure
> this creation based on some kind of parameters. Now where to you get
> those? Typically, from an XForms instance... You don't have access to
> any in an XForms model pipeline, because you are just in the process
> of creating the main XForms instance for the current page, so you are
> stuck using request parameters, or who knows what. So again, if
> possible, this should be reserved to very specific cases.
Yep.
> > The tests I have done seems to show that this is working but I was
> > wondering if these two actions could be done in the same pipeline
> > (this would let us centralise the definition of the "backend"
> > related to the form).
>
> You mean reading the instance from and writing it to a persistent
> store in the same pipeline? I would rather have one pipeline doing one
> function, and the other doing the other. That's how the BizDoc example
> works, for example. In fact, it has a data access layer with separate
> pipelines for creating, reading, updating and deleting (CRUD)
> documents, as well as providing a listing of all documents.
>
> > As I understand from the answers I have got so far, this is not
> > possible:
> >
> > * the purpose of the first pipeline is to build the model, the
> > instance isn't available at that moment and thus it's too early
> > to save it.
> > * In the second pipelines (where the instance is available), the
> > model has already be built and thus it's too late to load the
> > initial values.
>
> Now does my rambling above shed some light on the general problem, or
> have I made everything even blurrier? ;-)
No, that's much clearer by now.
Thanks!
Eric
--
Curious about Relax NG? Read my book online.
http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
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
