Request processor

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Request processor

ToddG
I've added the following processor to my XPL:

 <p:processor name="oxf:request">
        <p:input name="config" debug="CONFIG">
            <config>
                <include>/request</include>
            </config>
        </p:input>
        <p:output name="data" id="path" debug="REQUEST"/>
    </p:processor>
...
    <p:processor name="oxf:standard-xalan">
        <p:input name="data" href="#xml"/>
        <p:input name="request" href="#path" debug="PATH"/>
        <p:input name="config" href="xml_publish.xsl"/>
         <p:output name="data" ref="data" debug="DATA"/>
    </p:processor>

I'm expecting to see CONFIG, REQUEST, or PATH in the log file, but all
I see is DATA.

I then took the debug example and dropped it in, but it doesn't output
anything either:

    <p:processor name="oxf:debug">
        <p:input name="config">
            <config>Employee</config>
        </p:input>
        <p:input name="data">
            <employee>
                <firstname>John</firstname>
                <lastname>Smith</lastname>
            </employee>
        </p:input>
        <p:output name="data" id="emp"/>
    </p:processor>

I can see DATA, so I know something regarding log4j is working.  What
am I missing?


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
Does your stylesheet read the "request" input? If not, you won't see  
any debug information for PATH and CONFIG, as XPL operates in a lazy  
way.

-Erik

On Nov 21, 2007, at 4:11 PM, Todd Gochenour wrote:

> I've added the following processor to my XPL:
>
> <p:processor name="oxf:request">
>        <p:input name="config" debug="CONFIG">
>            <config>
>                <include>/request</include>
>            </config>
>        </p:input>
>        <p:output name="data" id="path" debug="REQUEST"/>
>    </p:processor>
> ...
>    <p:processor name="oxf:standard-xalan">
>        <p:input name="data" href="#xml"/>
>        <p:input name="request" href="#path" debug="PATH"/>
>        <p:input name="config" href="xml_publish.xsl"/>
>         <p:output name="data" ref="data" debug="DATA"/>
>    </p:processor>
>
> I'm expecting to see CONFIG, REQUEST, or PATH in the log file, but all
> I see is DATA.
>
> I then took the debug example and dropped it in, but it doesn't output
> anything either:
>
>    <p:processor name="oxf:debug">
>        <p:input name="config">
>            <config>Employee</config>
>        </p:input>
>        <p:input name="data">
>            <employee>
>                <firstname>John</firstname>
>                <lastname>Smith</lastname>
>            </employee>
>        </p:input>
>        <p:output name="data" id="emp"/>
>    </p:processor>
>
> I can see DATA, so I know something regarding log4j is working.  What
> am I missing?
>
> --
> 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
> OW2 mailing lists service home page: http://www.ow2.org/wws
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
Hmmm..   Well, no, actually the stylesheet doesn't yet.  I must have
been mistaken to think it sufficient that the xalan transformation
process "uses" the output of the request processor, but no, the XSL
stylesheet doesn't "use" the request object.  "Lazy" processing, you
say?  I don't see that anywhere in the documentation.  This would be a
good thing to know when trying to figure out best practices in writing
pipelines.

...I did a search on "lazy" and this article came up,
http://mail.orbeon.com/pipermail/oxf-users/2003-July/000317.html "why
can't a pipeline have processing steps that aren't hooked to the
pipeline's output?"

...Given what I read hear, I would think the "debug" processor would
be better documented without an output pipe, so that the example given
actually works when attempted.

    <p:processor name="oxf:debug">
        <p:input name="config">
            <config>Employee</config>
        </p:input>
        <p:input name="data">
            <employee>
                <firstname>John</firstname>
                <lastname>Smith</lastname>
            </employee>
        </p:input>
        <!-- p:output name="data" id="emp"/ -->
    </p:processor>

...except that when I test this it throws an exception "Start not
supported; processor implemented by
'org.orbeon.oxf.processor.DebugProcessor'".  Evidently the output pipe
is required, since I add it
back in and I get no error (and no output).

...from the article, I take it the bug
http://athlon.orbeon.com/webtools/bugzilla/show_bug.cgi?id=1218
written in 2003 hasn't been completed yet.  Oh, that webtool link
doesn't even work.  Yikes, I'm spiraling down a rabbit hole...

...Trying the "official" use of a null-serializer instead of a
session-serializer. I found in this article the statement
"This is the "official" way to force the output of a processor to be
read." I now have:

<p:processor name="oxf:debug">
        <p:input name="config">
            <config>Employee</config>
        </p:input>
        <p:input name="data">
            <employee>
                <firstname>John</firstname>
                <lastname>Smith</lastname>
            </employee>
        </p:input>
        <p:output name="data" id="emp"/>
</p:processor>

<p:processor name="oxf:null-serializer">
         <p:input name="data" href="#emp"/>
</p:processor>

and this throws a null pointer exception.  My experiment in debugging
based on what I read in the documentation has come to a dead-end.

...back to the original suggestion.  The stylesheet needs to read the
"request" input?

I've written my stylesheet to read:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:param name="request"/>
<xsl:template match="/">
        <xml_publish>
            <xml_param>
                <request><xsl:copy-of select="$request"/></request>
...

...and the resulting XML had <request/> in the stream.  No content
present.  The request processor isn't supplying anything,  What am I
missing?


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
And I read in the documentation about passing user defined parameters
to the stylesheets, that "Of course, the value does not have to be
static, it can be computed dynamically as well."

The example reads:

To set the start parameter with XPL, simply encapsulate the
my-stylesheet.xsl stylesheet as follows:

<p:processor name="oxf:xslt">
<p:input name="data" href="#stylesheet-input"/>
<p:input name="config">
<xsl:stylesheet version="2.0">
<xsl:import href="my-stylesheet.xsl"/>
<xsl:param name="start" select="'a2'"/>
</xsl:stylesheet>
</p:input>
<p:output name="data" id="stylesheet-output"/>
</p:processor>

So how do I do the dynamic compute?  This is not obvious.

Finding more in documentation, this doesn't work either:

<p:processor name="oxf:xslt">
<p:input name="data" href="#stylesheet-input"/>
<p:input name="config">
<xsl:stylesheet version="2.0">
<xsl:import href="my-stylesheet.xsl"/>
<xsl:param name="start" select="doc(input:request)"/>
</xsl:stylesheet>
</p:input>
<p:output name="data" id="stylesheet-output"/>
</p:processor>

This gives the exception "Failed to load document input:request".


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
Happy Thanksgiving,

This is day two of what should be a simple task: Capture KEY from the
request's path info and display associated XML fragment.  To date,
I've hard-coded the key in the eXist xpath query and displayed the
specific XML fragment.  Now I want to make it general across the
entire 39Meg file. I'm having no luck.

I've abandoned the request processor approach.  The way it's
documented doesn't work.

I'm now trying the page flow submission document approach.

I have in my page flow:

<page
   path-info="/SkyPreview/([^/]+)/([^/]+)/([^/]+)"
   matcher="oxf:perl5-matcher"
   default-submission="submit.xml"
   model="model.xpl"
   view="view.xpl">
        <setvalue ref="/form/customer" matcher-group="1"/>
        <setvalue ref="/form/fleet" matcher-group="2"/>
        <setvalue ref="/form/manual" matcher-group="3"/>
</page>

where submit.xml contains:

<form>
   <customer/>
   <fleet/>
   <manual/>
</form>

and model.xpl contains:

<p:config
   xmlns:p="http://www.orbeon.com/oxf/pipeline"
   xmlns:oxf="http://www.orbeon.com/oxf/processors"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <p:param name="instance" type="input"/>
        <p:param name="data" type="output"/>

  <p:processor name="oxf:xslt">
        <p:input name="config" debug="CONFIG">
        <config xsl:version="2.0">
                <xsl:variable name="instance" select="doc('input:instance')"/>
                <instance><xsl:copy-of select="$instance"/></instance>
...

and the Error Page is displayed with "Failed to load document
input:instance", which tells me the forms submission XML hasn't been
passed into the pipeline.

Again I fail to understand what the documentation tells me to do.  How
can I be this dense?

Dinner's ready.  Gobble gobble.


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
The mention of laziness is not directly in the doc, but it is in the  
XPL spec in the part about the processing model:

   http://www.w3.org/Submission/xpl/#d1056e1510

The mailing-list post you are pointing to is exactly to the point.  
Wow, 2003, that's scary ;-)

And yes you are right, it is very important to know about it. The  
"debug" attribute will produce a document if and only if a document  
goes through the input or output during the execution of the pipeline.

You should really not use the debug processor directly unless you have  
a very good reason to do so. Instead, just use the debug attribute on  
processor inputs and outputs. As the doc says: "Using debug attributes  
in pipelines is a shortcut for actually inserting the Debug processor  
in the pipeline: the Pipeline processor will insert a Debug processor  
when encountering debug attributes.".

Finally, instead of writing:

   <xsl:copy-of select="$request"/>

write:

   <xsl:copy-of select="doc('input:request')"/>

This is the way an XSLT stylesheet can read custom processor inputs:

   http://localhost:8080/ops/doc/processors-xslt#user-defined

I hope this gets you further!

-Erik

On Nov 21, 2007, at 11:42 PM, Todd Gochenour wrote:

> Hmmm..   Well, no, actually the stylesheet doesn't yet.  I must have
> been mistaken to think it sufficient that the xalan transformation
> process "uses" the output of the request processor, but no, the XSL
> stylesheet doesn't "use" the request object.  "Lazy" processing, you
> say?  I don't see that anywhere in the documentation.  This would be a
> good thing to know when trying to figure out best practices in writing
> pipelines.
>
> ...I did a search on "lazy" and this article came up,
> http://mail.orbeon.com/pipermail/oxf-users/2003-July/000317.html "why
> can't a pipeline have processing steps that aren't hooked to the
> pipeline's output?"
>
> ...Given what I read hear, I would think the "debug" processor would
> be better documented without an output pipe, so that the example given
> actually works when attempted.
>
>    <p:processor name="oxf:debug">
>        <p:input name="config">
>            <config>Employee</config>
>        </p:input>
>        <p:input name="data">
>            <employee>
>                <firstname>John</firstname>
>                <lastname>Smith</lastname>
>            </employee>
>        </p:input>
>        <!-- p:output name="data" id="emp"/ -->
>    </p:processor>
>
> ...except that when I test this it throws an exception "Start not
> supported; processor implemented by
> 'org.orbeon.oxf.processor.DebugProcessor'".  Evidently the output pipe
> is required, since I add it
> back in and I get no error (and no output).
>
> ...from the article, I take it the bug
> http://athlon.orbeon.com/webtools/bugzilla/show_bug.cgi?id=1218
> written in 2003 hasn't been completed yet.  Oh, that webtool link
> doesn't even work.  Yikes, I'm spiraling down a rabbit hole...
>
> ...Trying the "official" use of a null-serializer instead of a
> session-serializer. I found in this article the statement
> "This is the "official" way to force the output of a processor to be
> read." I now have:
>
> <p:processor name="oxf:debug">
>        <p:input name="config">
>            <config>Employee</config>
>        </p:input>
>        <p:input name="data">
>            <employee>
>                <firstname>John</firstname>
>                <lastname>Smith</lastname>
>            </employee>
>        </p:input>
>        <p:output name="data" id="emp"/>
> </p:processor>
>
> <p:processor name="oxf:null-serializer">
>         <p:input name="data" href="#emp"/>
> </p:processor>
>
> and this throws a null pointer exception.  My experiment in debugging
> based on what I read in the documentation has come to a dead-end.
>
> ...back to the original suggestion.  The stylesheet needs to read the
> "request" input?
>
> I've written my stylesheet to read:
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  
> version="1.0">
> <xsl:param name="request"/>
> <xsl:template match="/">
>        <xml_publish>
>            <xml_param>
>                <request><xsl:copy-of select="$request"/></request>
> ...
>
> ...and the resulting XML had <request/> in the stream.  No content
> present.  The request processor isn't supplying anything,  What am I
> missing?
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
> <p:processor name="oxf:xslt">

> <p:input name="data" href="#stylesheet-input"/>
> <p:input name="config">
> <xsl:stylesheet version="2.0">
> <xsl:import href="my-stylesheet.xsl"/>
> <xsl:param name="start" select="doc(input:request)"/>
> </xsl:stylesheet>
> </p:input>
> <p:output name="data" id="stylesheet-output"/>
> </p:processor>
>
> This gives the exception "Failed to load document input:request".
Because you did not connect an input called "request".

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
>  <p:processor name="oxf:xslt">

>        <p:input name="config" debug="CONFIG">
> <config xsl:version="2.0">
> <xsl:variable name="instance" select="doc('input:instance')"/>
> <instance><xsl:copy-of select="$instance"/></instance>
> ...
>
> and the Error Page is displayed with "Failed to load document
> input:instance", which tells me the forms submission XML hasn't been
> passed into the pipeline.
>
> Again I fail to understand what the documentation tells me to do.
What doc('input:instance') does is tell the XSLT processor to read an  
input of that processor called "instance". The error saying that the  
stylesheet cannot read a document called "input:instance" is correct,  
since no such document exists. For that to happen, you must connect  
such an input called "instance". So write instead:

   <p:processor name="oxf:xslt">
        <p:input name="config" debug="CONFIG">
        <p:input name="instance" href="#instance"/>
        <config xsl:version="2.0">
                <xsl:variable name="instance" select="doc('input:instance')"/>
                <instance><xsl:copy-of select="$instance"/></instance>

It's really a matter of pipes, the trick is to understand what needs  
to be connected where ;-)

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
In reply to this post by Erik Bruchez
Oh, I see.  My experience with XSL led me to believe that inputs to an
XSLT transformation would be passed in via parameters.  I see now they
are doc() references instead.  It would be nice if an example of this
was present in the Request Generator page of the User Guide.

The XPL spec submitted to W3C...I've always had a problem reading the
formal structure of any of these documents.  I manage best I can.  I
know of but haven't bothered reading the submission for XPL hoping I
could "grok" it faster using the User's Guide.  Is there a formal
process for logging requests for change to the User Guide?  I now have
two.

1) Reference to "lazy evaluation" of processors in the "Introduction
to XPL" and also under Debug Processor, so one can know that adding
debug="TOKEN" won't necessarily produce output in the log file.
2) With the XSLT Generator, a notice that inputs from other pipelines
use the doc() reference, as futher documented under the user-defined
section you presented.


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
I spoke incorrectly.  For Item 2) above the user-defined section
already IS in the xslt processor documentation.  What I meant to say
was that the "Passing Parameters" should have an example that
demonstrates the input of another document.  <CURRENT_REALIZATION>The
fact that the "parameters" section is immediately after the
"user-defined inputs" section just points to how dense I can be
sometimes, now that I read the two sections together as one.  I mean,
aren't these identical concepts, inputs and
parameters?</CURRENT_REALIZATION>


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
In reply to this post by Erik Bruchez
Oh I see.   It's not sufficient that the pipeline's has an input
parameter called "instance", I need to add an input into the XSLT
processor and connect it to the parameter of the pipeline.  So I have
a third modification to the documentation:

3) Notice that the pipeline's input parameter is NOT the same thing as
a processor's input, and that the one has to be connected to the
other, and then the input is connected to the stylesheet via a
doc(input:X) reference.

pipeline:param(type=input, name=instance) -->
processor:input(name=instance, href="#instance") -->
xslt:doc(input:instance)

These three concepts are documented in three different places in the
Uesr Guide and not tied together in this particular manner (or at
least not obvious enough for someone working long hours trying to get
a prototype completed).


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

ToddG
I ultimately got frustrated with the various validation error pages
and abandoned use of the page flow controller and processor pipeline.
I used a two-pass XSLT strategy, first pass into a variable, second
pass using exslt:node-set($variable) to handle my poor man's XML
pipeline, and then used eXist's REST interface to perform the XPath
query and transform the result with my 2 pass XSLT.  It works but with
ugly URL structure.  I'll come back to Orbeon soon, I'm sure, because
I'll need a controller eventually to pass configuration parameters
into my XSLT.  Far as I can tell, the eXist REST interface doesn't
allow for that.

Anyway, thanks Erik.  You give great support.  I like the technology
strategy your company provides.


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
Well, yes and no. XPL does not have a native mechanism to pass XSLT  
parameters. However, it has a mechanism to pass extra documents  
available through the doc() function. I have made a clarification in  
the doc about this.

Note that the XProc pipeline language, which we are now developing  
under the umbrella of W3C, will however support XSLT parameters  
natively.

-Erik

On Nov 26, 2007, at 11:51 PM, Todd Gochenour wrote:

> I spoke incorrectly.  For Item 2) above the user-defined section
> already IS in the xslt processor documentation.  What I meant to say
> was that the "Passing Parameters" should have an example that
> demonstrates the input of another document.  <CURRENT_REALIZATION>The
> fact that the "parameters" section is immediately after the
> "user-defined inputs" section just points to how dense I can be
> sometimes, now that I read the two sections together as one.  I mean,
> aren't these identical concepts, inputs and
> parameters?</CURRENT_REALIZATION>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
Todd,

Thanks a lot. I have made clarifications about this in the XSLT  
processor documentation.

-Erik

On Nov 27, 2007, at 12:05 AM, Todd Gochenour wrote:

> Oh I see.   It's not sufficient that the pipeline's has an input
> parameter called "instance", I need to add an input into the XSLT
> processor and connect it to the parameter of the pipeline.  So I have
> a third modification to the documentation:
>
> 3) Notice that the pipeline's input parameter is NOT the same thing as
> a processor's input, and that the one has to be connected to the
> other, and then the input is connected to the stylesheet via a
> doc(input:X) reference.
>
> pipeline:param(type=input, name=instance) -->
> processor:input(name=instance, href="#instance") -->
> xslt:doc(input:instance)
>
> These three concepts are documented in three different places in the
> Uesr Guide and not tied together in this particular manner (or at
> least not obvious enough for someone working long hours trying to get
> a prototype completed).
>
> --
> 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
> OW2 mailing lists service home page: http://www.ow2.org/wws
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Request processor

Erik Bruchez
Administrator
In reply to this post by ToddG
Thanks Todd. Feedback about difficulties encountered by users is what  
makes Orbeon Forms get better and better. I hope you do get back to  
Orbeon Forms, and that you also give XForms support in Orbeon Forms a  
try as well, as XForms and eXist make a great combination.

-Erik

On Nov 27, 2007, at 12:16 AM, Todd Gochenour wrote:

> I ultimately got frustrated with the various validation error pages
> and abandoned use of the page flow controller and processor pipeline.
> I used a two-pass XSLT strategy, first pass into a variable, second
> pass using exslt:node-set($variable) to handle my poor man's XML
> pipeline, and then used eXist's REST interface to perform the XPath
> query and transform the result with my 2 pass XSLT.  It works but with
> ugly URL structure.  I'll come back to Orbeon soon, I'm sure, because
> I'll need a controller eventually to pass configuration parameters
> into my XSLT.  Far as I can tell, the eXist REST interface doesn't
> allow for that.
>
> Anyway, thanks Erik.  You give great support.  I like the technology
> strategy your company provides.
>
> --
> 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
> OW2 mailing lists service home page: http://www.ow2.org/wws
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Problems with <xforms:submission replace="all"> when used with ev:event="xforms-ready"

Markku Laine
Hey,


I think there is a bug in Orbeon Forms when sending an <xforms:submission
replace="all"> request triggered by ev:event="xforms-ready". The
submission won't be executed. However, if the submission request is
triggered manually by clicking a button then it works fine. Also, if
replace="all" is changed to replace="instance" in the xforms:submission,
then ev:event="xforms-ready" works fine, too.

Please, see the example code below. Change replace="all" to
replace="instance" or trigger the request manually and see what happens.

I am using Orbeon Forms 3.6.0rc1.

Yours sincerely,


-Markku Laine


data.xml
--------
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="">Hello World!</data>

index.xhtml
-----------
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
       xml:lang="en"
       lang="en"
       xmlns:ev="http://www.w3.org/2001/xml-events"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xforms="http://www.w3.org/2002/xforms">
  <head>
  <title>Problems with &lt;xforms:submission
replace="all"&gt; when used with ev:event="xforms-ready"</title>
  <xforms:model>
  <xforms:instance id="data-instance">
  <data xmlns="">Default</data>
  </xforms:instance>
  <xforms:submission id="data-submission"
replace="all" ref="instance( 'data-instance' )" action="data.xml"
method="get" mediatype="application/xml" encoding="UTF-8" />
  <xforms:send submission="data-submission"
ev:event="xforms-ready" />
  </xforms:model>
  </head>
  <body>
  <h1>Problems with &lt;xforms:submission replace="all"&gt;
when used with ev:event="xforms-ready"</h1>
  <p>
  <xforms:output ref="instance( 'data-instance' )"
/><br />
  <xforms:trigger>
  <xforms:label>Submit</xforms:label>
  <xforms:action ev:event="DOMActivate">
  <xforms:send
submission="data-submission" />
  </xforms:action>
  </xforms:trigger>
  </p>
  </body>
</html>


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Problems with <xforms:submission replace="all" method="post">

Markku Laine
Hey,


I am submitting a request using the following submission element (just a
simple example):
<xforms:submission id="post-submission" replace="all"
action="http://www.w3.org" method="post" />

Should the URL be replaced with the one defined in the action attribute?
At the moment, the URL is always replaced with:
http://localhost:8080/ops/xforms-server-submit

Where http://localhost:8080 is the domain that I am using and /ops is
configured to be the URL of Orbeon Forms XForms filter.


The problem is that if the response received from the server contains
relative URLs (e.g., a generated XHTML+XForms page with links to CSS
files), they will break down. You can see this happening in my simple
example, which ought to replace the document with the W3C web page. As you
can see, the document is replaced but relative CSS files do not work
due to incorrect URL.

The example document below can be used to test the problem with
replace="all" when used with "xforms-ready" event, too.

Regards


-Markku

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
       xml:lang="en"
       lang="en"
       xmlns:ev="http://www.w3.org/2001/xml-events"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xforms="http://www.w3.org/2002/xforms">
  <head>
  <title>Problems with &lt;xforms:submission
replace="all"&gt; when used with method="post"</title>
  <xforms:model>
  <xforms:submission id="post-submission"
replace="all" action="http://www.w3.org" method="post" />
  <xforms:send submission="post-submission"
ev:event="xforms-ready" />
  </xforms:model>
  </head>
  <body>
  <h3>Problems with &lt;xforms:submission replace="all"&gt;
when used with method="post"</h3>
  <p>
  <xforms:trigger>
  <xforms:label>Submit
request</xforms:label>
  <xforms:action ev:event="DOMActivate">
  <xforms:send
submission="post-submission" />
  </xforms:action>
  </xforms:trigger>
  </p>
  </body>
</html>


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Problems with <xforms:submission replace="all" method="post">

Erik Bruchez
Administrator
Marrku,

I understand the problem, but in most cases it is not possible to  
change the URL in the browser when doing such a POST.

The reason is that the submission is not executed by the web browser,  
but by Orbeon Forms on the server. So unfortunately when you are doing  
a POST or PUT with replace="all", we don't show the URL you expect. As  
you noted, this causes problems, but I am not sure there is a way  
around it.

If you do a submission with method="get", on the other hand, things  
will work.

One reason for this situation is manyfold. Say you want to POST XML to  
a URL, and get an HTML page back, as in your example: I do not believe  
this is actually possible directly from a web browser. A number of  
other submission scenarios, allowed by XForms, are simply not  
supported in web browser. So we resort to performing submissions from  
the server, which turns out to have also benefits, like the fact that  
your XForms instances are never accessible in the user's web browser.

-Erik

On Dec 2, 2007, at 5:03 PM, .::: Markku :::. wrote:

> Hey,
>
>
> I am submitting a request using the following submission element  
> (just a simple example):
> <xforms:submission id="post-submission" replace="all" action="http://www.w3.org 
> " method="post" />
>
> Should the URL be replaced with the one defined in the action  
> attribute? At the moment, the URL is always replaced with: http://localhost:8080/ops/xforms-server-submit
>
> Where http://localhost:8080 is the domain that I am using and /ops  
> is configured to be the URL of Orbeon Forms XForms filter.
>
>
> The problem is that if the response received from the server  
> contains relative URLs (e.g., a generated XHTML+XForms page with  
> links to CSS files), they will break down. You can see this  
> happening in my simple example, which ought to replace the document  
> with the W3C web page. As you can see, the document is replaced but  
> relative CSS files do not work due to incorrect URL.
>
> The example document below can be used to test the problem with  
> replace="all" when used with "xforms-ready" event, too.
>
> Regards
>
>
> -Markku
>
> <?xml version="1.0" encoding="UTF-8"?>
> <html xmlns="http://www.w3.org/1999/xhtml"
>      xml:lang="en"
>      lang="en"
>      xmlns:ev="http://www.w3.org/2001/xml-events"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xmlns:xs="http://www.w3.org/2001/XMLSchema"
>      xmlns:xforms="http://www.w3.org/2002/xforms">
> <head>
> <title>Problems with &lt;xforms:submission replace="all"&gt; when  
> used with method="post"</title>
> <xforms:model>
> <xforms:submission id="post-submission" replace="all" action="http://www.w3.org 
> " method="post" />
> <xforms:send submission="post-submission" ev:event="xforms-
> ready" />
> </xforms:model>
> </head>
> <body>
> <h3>Problems with &lt;xforms:submission replace="all"&gt; when  
> used with method="post"</h3>
> <p>
> <xforms:trigger>
> <xforms:label>Submit request</xforms:label>
> <xforms:action ev:event="DOMActivate">
> <xforms:send submission="post-submission" />
> </xforms:action>
> </xforms:trigger>
> </p>
> </body>
> </html>
>
> --
> 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
> OW2 mailing lists service home page: http://www.ow2.org/wws
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws