Webservices

Posted by Rob Harker on
URL: https://discuss.orbeon.com/Tutorial-Questions-tp30743p30745.html

Hello All

I am new to Orbeon and am currently looking into using the Orbeon
Presentation Server to implement and on-line shopping cart. I am however
having problems trying to pass the Xforms instance data as a single
parameter to a C# web service. I have full control of the web service
parameters and am looking for guidance that could help me overcome this
problem. I have successfully used the oxf:delegation processor to pass
strings and integers, but cannot seem to pass xml documents/fragments.

Any help or guidance in this matter would be greatly appreciated.

Many thanks

Robert Harker

* +44 (0) 1524 271169
* +44 (0) 7966 277836
* [hidden email]

The information contained in this message (including attachments) may be
privileged and confidential and protected from disclosure. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately by replying to the
message and deleting it from your computer. Thank you. Robert Harker


-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 02 October 2006 16:57
To: [hidden email]
Subject: Re: [ops-users] Tutorial Questions

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-submission

What 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