> 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.
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.
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.
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.
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.
> 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? ;-)
-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
