Posted by
Erik Bruchez on
URL: https://discuss.orbeon.com/Tutorial-Questions-tp30743p30744.html
Mark,
> I am basing this email on the existing Tutorial, which I know is
> outdated.
>
> (1) Starting on page 13, an <action/> element is added to the xml
> instance, in order to store the action taken by the user so the
> appropriate successor page can be selected. This seems a bit
> kludgy. I view the xml instance as a pure business object, storing
> on the data that I want to use for my business. I shouldn't be
> forced to add additional information that controls simply the page
> flow for a given session. Instead, either a separate action
> instance object should be declared and used or OPS should embed an
> implicit forward name that can be accessed by the next process.
You are absolutely right. As you say, the tutorial is outdated, and we
don't encourage using an <action> element in an XForms
anymore. Instead, you can:
o Use URLs to control actions. You can control the action dynamically
using, for example:
<xforms:submission
action="/my/path/{instance('action-instance')/action)}" .../>
o Use HTTP methods. For example, instead of POSTing to
/my/path/delete, perform an HTTP DELETE on a URI that identifies the
resource to delete, e.g.:
/my/path/my-resource
In the more complex cases, unfortunately, you will still have to embed
such information in the XML document you submit from XForms, as XForms
doesn't have the ability to submit multiple instances at the same time
at the moment (e.g. with the multipart/related mediatype). However,
improved XForms 1.1 constructs allow you to dynamically build such an
XML document from the XForms page, so you can keep the instances
"clean" in your XForms page, and combine them together at the time of
submission.
> (2) Similarly, as shown on page 14, when one process ends up with an
> xml instance, the only way to "pass" this instance on to the next
> process in the pipeline is to create an empty instance and then
> populate it, using value-of, with the values from the previous
> process. There should be an easier way to give a name to the xml
> instance in the first process and simply reference it in the 2nd
> instance, without the addtl overhead. I believe something like this
> is shown later on in the tutorial.
OPS 3.0 and above look at this in terms of "XML submissions": a page
declared in the page flow can receive a submission, which typically
contains an XML document. That submission can be external (e.g. XForms
page POSTing an XML document) or internal (page in the page flow
submitting an XML document to another page in the page flow).
http://www.orbeon.com/ops/doc/reference-page-flow#xml-submissionWhat this section of the tutorial does is create an "internal"
submission, i.e. the result of a source page is an XML document which
is then adapted or transformed into another XML document before being
sent (internally) to a destination page. Note that ith 3.0 and above:
o Using XUpdate to achieve this is deprecated (because XUpdate itself
as a language is unfortunately). We recommend using XSLT instead.
o That mechanism is completely independent from XForms, and we would
like to keep things that way. This doesn't mean we can't make
internal submissions easier to build, of course, but how to do that
is up for grabs.
o You tend to use the internal submission mechanism less, because
XForms now gives you so much more control over submissions. In the
simple cases, the logic that decides "what to do next" in a process
can be in the XForms page itself, and you use different submission
URIs to control your flow.
-Erik
--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/--
You receive this message as a subscriber of the
[hidden email] mailing list.
To unsubscribe: mailto:
[hidden email]
For general help: mailto:
[hidden email]?subject=help
ObjectWeb mailing lists service home page:
http://www.objectweb.org/wws