This is great, thanks for a solution and the nice example.
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.
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!, eg.,
<action when="/form/action = 'next'">
<result page="xforms-wizard-lastname">
<xu:update select="/form/user"
xmlns:xu="http://www.xmldb.org/xupdate";>
<xu:copy-of select="document('#instance')/form/user/*"/>
</xu:update>
</result>
</action>
What are OXF's other hidden features?
Thanks again for your help.
-Scott
UC Berkeley Center for Document Engineering
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Alessandro Vernet
> Sent: Thursday, July 17, 2003 5:39 PM
> To: OXF Users
> Subject: Re: XForms processing step destroys XForms data not explicitly
> collected by the view
>
>
> Hi Scott,
>
> The architecture you propose sounds good. Instead of merging in the
> model, the instance that comes in input with the instance stored in
> the session, you could use an XPL that generates the XForms model by
> using what is stored in the session. Now with the new Web application
> controller in OXF 2.0, the preferred way to do this is to let the
> controller pass the XForms instance across pages (and this is what you
> suggest at the end of your email).
>
> Since this is a frequent scenario, we have added a "wizard example" to
> the OXF showcase application. I think that this example will answer
> your question. It will be bundled with the next release of OXF, but
> you can already view it online at:
>
> http://www.orbeon.com/oxf/examples/xforms-wizard-firstname
>
> Alex
>
>
> Scott McMullan wrote:
> > Question about multi-screen collection of data to fill in a
> single XForm.
> > Let's assume we want to fill in a simple document (an XForm
> instance) with 3
> > elements, but we want to do it over 3 screens, filling in 1 element per
> > screen. To accomplish this right now, we are keeping a partially filled
> > copy of the XForms instance document in the session, and after
> each screen,
> > we xupdate the newly collected element(s) into the existing
> partially filled
> > instance stored in the session. At the end of the 3rd screen, we've
> > successfully filled in the the entire XForm.
> >
> > HOWEVER, a better approach is to SKIP THE XUPDATE step, and
> instead use a
> > .xpl to build our XForm dynamically, by having it pull the
> partially filled
> > XForm out of the session and passing that into the view,
> instead of a blank
> > copy each time, as we do currently. The problem seems to be
> that the OXF
> > XForms processor DOES NOT pass the previously collected XFOrms
> data through
> > onto the next step -- it assumes that the instance document to
> pass along
> > consists of ONLY the new data collected on that given screen --
> effectively
> > defeating our attempt to build up the filled in XForms instance
> one screen
> > at a time.
> >
> > Is there any reason a given screen's forms submission/XForms
> processing step
> > must trash data in the XForms instance document just because it wasn't
> > collected on that screen?
> >
> > Thanks.
> >
> > -Scott
> > UC Berkeley Center for Document Engineering
> >
> > _______________________________________________
> > oxf-users mailing list
> > [EMAIL PROTECTED]
> > http://mail.orbeon.com/mailman/listinfo/oxf-users
>
> _______________________________________________
> oxf-users mailing list
> [EMAIL PROTECTED]
> http://mail.orbeon.com/mailman/listinfo/oxf-users
_______________________________________________
oxf-users mailing list
[EMAIL PROTECTED]
http://mail.orbeon.com/mailman/listinfo/oxf-users
