Web service question

> On 4/12/06, David Sinclair <[hidden email]> wrote:
>  
>> I am guessing but doesnt the xforms engine have to do a very similar
>> when doing submissions?
>>    
>
> Hi Dave,
>
> Indeed, and in fact one thing you can do is to call the xforms-server
> from a pipeline. OK, this is not trivial, but the pipeline attached to
> this email (submit.xpl) does the heavy lifting. All you have to do is
> call it with two input documents: "request" is the document you want
> to post, and "submission" contains an XForms submission with the
> action and method to use. The result comes back in the "response"
> output. In fact this can be useful in a number of cases, so I checked
> it in ops/utils in the resources.
>
>  

> <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline"
>     xmlns:xforms="http://www.w3.org/2002/xforms"
>     xmlns:oxf="http://www.orbeon.com/oxf/processors">
>
>     <p:param name="data" type="output"/>
>
>     <p:processor name="oxf:pipeline">
>         <p:input name="config" href="oxf:/ops/utils/submit.xpl"/>
>         <p:input name="submission">
>             <xforms:submission method="post"
> action="http://localhost:8080/ops/direct/xforms-translate/post"/>
>         </p:input>
>         <p:input name="request">
>             <translation>
>                 <source>This is a table.</source>
>                 <language-pair>en|fr</language-pair>
>             </translation>
>         </p:input>
>         <p:output name="response" ref="data"/>
>     </p:processor>
>
> </p:config>
>
>
> Alex
> --
> Blog (XML, Web apps, Open Source):
> 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
>  

> David,
>
> Sounds good. You'll let us know how it works. It might look like it is
> suboptimal to bring out the whole XForms artillery to do a POST, but
> at the same time I makes sense to me to leverage the XForms submission
> mechanism which is standard, well defined, quite powerful, and
> definitely here to stay.
>
> This is also in harmony with the efforts of the XForms working group
> who is working on making the XForms model reusable as just a data
> model, in contexts other than XHTML, SVG, or similar.
>
>  

> Alex
> --
> Blog (XML, Web apps, Open Source):
> 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
>  

> David Sinclair wrote:
>
> > Sorry for taking so long to get back to you on this one...easter got in
> > the way!  Anyway I have this working fine now ... one question I have is
> > what to do about exceptions.   If the remote pipeline has an exception
> > then all the client sees is the instance it passed in as the output.  I
> > could try to ensure exceptions are always handled in the pipeline
> > providing the service but it would be good to know there was some
> > generic way of making sure that if an error occurs the client knows
> > about it.  Any ideas?
>
> Note sure if this makes sense in your case, but if your services are
> handled by a different OPSServlet, then you can specify an error
> pipeline (called upon exception) that is different from the error
> pipeline that displays the usual exception in your browser.
>
> Your "service" servlet can then format an error response to send to the
> client. This is what the XForms Server servlet does exactly: upon error,
> it uses the exception generator to format an exception and sends that to
> the client.
>
> This way, your XForms page will receive an error document upon
> exceptions occurring in a service, and you can detect that (with
> relevance, for example).
>
> Another way would be to use HTTP return codes to communicate to the
> XForms page that an error has occurred. This will cause an
> xforms-submit-error event to be sent.
>
> Note that this question is still an open question for the XForms working
> group, in that XForms does not really have a mean currently to
> differentiate between submission errors that are related to the
> protocol, in this case HTTP, and those related to internal conditions,
> for example an invalid XForms instance being submitted.
>
> -Erik
>
> einfaches Textdokument-Anlage (message-footer.txt)
> --
> 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

> David Sinclair wrote:
>
>> Sorry for taking so long to get back to you on this one...easter got
>> in the way!  Anyway I have this working fine now ... one question I
>> have is what to do about exceptions.   If the remote pipeline has an
>> exception then all the client sees is the instance it passed in as
>> the output.  I could try to ensure exceptions are always handled in
>> the pipeline providing the service but it would be good to know there
>> was some generic way of making sure that if an error occurs the
>> client knows about it.  Any ideas?
>
> Note sure if this makes sense in your case, but if your services are
> handled by a different OPSServlet, then you can specify an error
> pipeline (called upon exception) that is different from the error
> pipeline that displays the usual exception in your browser.
>
> Your "service" servlet can then format an error response to send to
> the client. This is what the XForms Server servlet does exactly: upon
> error, it uses the exception generator to format an exception and
> sends that to the client.
>

> This way, your XForms page will receive an error document upon
> exceptions occurring in a service, and you can detect that (with
> relevance, for example).
>
> Another way would be to use HTTP return codes to communicate to the
> XForms page that an error has occurred. This will cause an
> xforms-submit-error event to be sent.
>
> Note that this question is still an open question for the XForms
> working group, in that XForms does not really have a mean currently to
> differentiate between submission errors that are related to the
> protocol, in this case HTTP, and those related to internal conditions,
> for example an invalid XForms instance being submitted.
>
> -Erik
>
> ------------------------------------------------------------------------
>
>
> --
> 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
>  

>>
> Hi Eric / Alex,
>
> This sounds like a good approach, thanks.
> However I think there is still a gap in my understanding of how to
> achieve this.   At the moment I have 2 ops applications.  One has a
> page thats lest you enter some query parameters...when you press a 'do
> query' button it formats a request and uses Alex's submit pipline to
> invoke the other ops application.   This works fine when no error
> occurs.  If I deliberately make a change to the service application
> such that it throws an exception I seem to get a 500 error returned (I
> am using a http sniffer to see the traffic at the http level).  The
> body seems to have some truncated html in it which presume is the
> output from the standard error pipeline.   If I format the error how I
> want using my own error pipeline I still dont understand how I can get
> access to this XML? the submit pipeline just seems to be giving me the
> input I passed to it as the output in the error condition...what am I
> missing here, something obvious no doubt...
>

> Dave
>
>
>> This way, your XForms page will receive an error document upon
>> exceptions occurring in a service, and you can detect that (with
>> relevance, for example).
>>
>> Another way would be to use HTTP return codes to communicate to the
>> XForms page that an error has occurred. This will cause an
>> xforms-submit-error event to be sent.
>>
>> Note that this question is still an open question for the XForms
>> working group, in that XForms does not really have a mean currently
>> to differentiate between submission errors that are related to the
>> protocol, in this case HTTP, and those related to internal
>> conditions, for example an invalid XForms instance being submitted.
>>
>> -Erik
>>
>> ------------------------------------------------------------------------
>>
>>
>> --
>> 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
>>  
>
>
> ------------------------------------------------------------------------
>
>
> --
> 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
>