Orbeon Forms community mailing list

Still missing something fundamental with XForms NG and a couple of comments

Classic

List

Threaded

24 messages Options

Eric van der Vlist

Still missing something fundamental with XForms NG and a couple of comments

Hi,

I think am still missing something pretty fundamental with XForms NG...
Also, I have a couple of comments on what I think I have understood...

I have a page defined as:

<page path-info="/sandbox/a" view="a.xhtml"/>

Where a.xhtml is:

<?xml version="1.0" encoding="UTF-8"?>
<html version="2.0" xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xxforms="http://orbeon.org/oxf/xml/xforms"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xi="http://www.w3.org/2001/XInclude">
<head>
<title>A</title>
<xforms:model>
<xforms:instance src="oxf:/sandbox/instance.xml"/>
<xforms:bind nodeset="/instance/decimal" type="xs:decimal"/>
<xforms:submission id="b" method="post"
action="http://whatever.com"/>
</xforms:model>
</head>
<body>
<xforms:group>

<xforms:range ref="/instance/decimal" start="0" end="1"
step=".1">
<xforms:label>Decimal: </xforms:label>
<xforms:hint>This is a decimal</xforms:hint>
<xforms:help>Blah blah...</xforms:help>
</xforms:range>


<xforms:input ref="/instance/string" style="width: 20em">
<xforms:label>String: </xforms:label>
<xforms:hint>This is a string</xforms:hint>
<xforms:help>Blah blah...</xforms:help>
</xforms:input>


<xforms:submit submission="b">
<xforms:label>B</xforms:label>
</xforms:submit>

</xforms:group>
</body>
</html>

First the comments:

1) The range doesn't seem to take the initial value into account, it seems
to ignore the start, end and step attributes and it doesn't display well
with its xforms sub elements (see capture attached)...

2) in the doc, you mention initializing the xforms instance using XInclude
or xsl:copy-of but you don't mention using the src attribute that seems
much easier. Is there a reason why we should avoid it? Also, the base URL
for this src attribute appears to be oxf:/ops/pfc/ which isn't really what
I would have expected...

Now what I really don't understand:

Whatever the value of the XForms submission action attrubte is, I get
redirected to /orbeon/xforms-server-submit. How can my submission be
redirected to the location defined in the action attribute?

Thanks,

Eric

PS: you'll find attached a capture showing how the range is displayed and
a zip file with this example.

sandbox.zip (58K) Download Attachment

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

>
> PS: you'll find attached a capture showing how the range is displayed and
> a zip file with this example.
>
Here is the capture...

Eric

Capture.png (60K) Download Attachment

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

> 1) The range doesn't seem to take the initial value into account, it
> seems to ignore the start, end and step attributes and it doesn't
> display well with its xforms sub elements (see capture attached)...

I think this just means that the range control is incompletely
implemented. I added a bug to track this:

https://forge.objectweb.org/tracker/index.php?func=detail&aid=304281&group_id=168&atid=350207

> 2) in the doc, you mention initializing the xforms instance using
> XInclude or xsl:copy-of but you don't mention using the src
> attribute that seems much easier. Is there a reason why we should
> avoid it? Also, the base URL for this src attribute appears to be
> oxf:/ops/pfc/ which isn't really what I would have expected...

This is one reason we are not "advertizing" this right now: relative
URLs are not handled correctly. This is already a related bug:

https://forge.objectweb.org/tracker/index.php?func=detail&aid=303809&group_id=168&atid=350207

But you can use absolute paths.

For dynamically generated instances, one thing that we would like to
have would be this:

<xforms:instance src="input:instance"/>

But the mechanisms to implement this are not yet there. There is now
an RFE for this:

https://forge.objectweb.org/tracker/index.php?func=detail&aid=304282&group_id=168&atid=350210

So in the meanwhile we still recommend:

<xforms:instance>
<xi:include href="input:instance"/>
</xforms:instance>

Also, when the XPointer facilities are in for XInclude, this solution
will be a tad more flexible.

> Now what I really don't understand:
>
> Whatever the value of the XForms submission action attrubte is, I
> get redirected to /orbeon/xforms-server-submit. How can my
> submission be redirected to the location defined in the action
> attribute?

At the moment, it can't. Remember, submissions are not performed by
your browser, they are performed by the XForms engine which resides on
the server!

In the future, some cases can be optimized, for example an easy one is
GET with replace="all", and possibly others depending on tricks we may
be able to implement on the client-side (suggestions welcome).

-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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

Hi Erik,

Le dimanche 13 novembre 2005 à 12:27 +0100, Erik Bruchez a écrit :

.../...

> > Now what I really don't understand:
> >
> > Whatever the value of the XForms submission action attrubte is, I
> > get redirected to /orbeon/xforms-server-submit. How can my
> > submission be redirected to the location defined in the action
> > attribute?
>
> At the moment, it can't. Remember, submissions are not performed by
> your browser, they are performed by the XForms engine which resides on
> the server!

Hmmm... I had underestimated the consequences of this statement!

I have looked into the server logs and taken traces of the network
exchanges to make sure I really get it right and, correct me if I am
wrong, the situation seems to be the following:

The XForm submission defined as:

<xforms:submission id="b" method="post" replace="all"
action="/sandbox/a"/>

Triggers a submission from the browser which is an HTTP POST with an
"application/x-www-form-urlencoded" content to the
address /orbeon/xforms-server-submit.

(There are other submissions to /orbeon/xforms-server but I guess that
they are part of the Ajax exchanges necessary to support XML events.)

While serving this POST to /orbeon/xforms-server-submit, the server then
behaves like if this request had been a POST of an XML document
to /sandbox/a.

I don't want to be harsh, but I think that you just can't do that!

IMO, this is bad from a user and designer point of view: URIs are
important. I don't like web applications where the URI doesn't show what
you're doing and I wouldn't want to deploy an application where all the
edits are done through the same /orbeon/xforms-server-submit URI.

Maybe more important, this isn't conform to the XForms recommendation.

XForms defines very precisely what a submit is and I think that if you
POST "application/x-www-form-urlencoded" content
to /orbeon/xforms-server-submit, you should describe it as:

<xforms:submission id="b" method="urlencoded-post" replace="all"
action="/orbeon/xforms-server-submit"/>

and that it would be more honest to say that you accept only the
urlencoded-post method to a specific address :-) ...

Now, I admit that the XForms specification doesn't say that an
application can't be distributed between the client and the server, use
an urlencoded-post between the client and the server and then performs
an XML POST between the server part of the XForms implementation and an
HTTP server. But still, there would need to be a POST of the XML
instance document to be conform to the XForms recommendation and I don't
think you can say that this POST is virtual and that you just simulate
one.

In other words, I think that to be conform to the XForms req, the POST
to /orbeon/xforms-server-submit should perform a "physical" XML POST as
described by the rec to /orbeon/sandbox/a. This would have the added
benefit that you would support external URIs.

If you really want to do what you're doing right now (which is probably
more efficient), I think that you should define your own method in a
specific namespace:

<xforms:submission id="b" method="ops:pseudo-post" replace="all"
action="/sandbox/a"/>

Note that wouldn't solve by first point about the unique URI.

About that first point, why couldn't the XForms server engine intercept
urlencoded-post posts to every pages and not
only /orbeon/xforms-server-submit?

That was more or less what OPS 2.8 was doing, couldn't OPS 3.0 continue
to so?

In other words, I think that both:

<xforms:submission id="b" method="urlencoded-post" action="/sandbox/a"/>
and
<xforms:submission id="b" method="ops:post" action="/sandbox/a"/>

would be fine if they were triggering the page "/sandbox/a"...

The last solution (and probably the best one) would be to do a real XML
POST submission in Javascript from the browser... Maybe in a next
version?

Thanks,

Eric (again, not wanting to be harsh but just constructive!)

--
Le premier annuaire des apiculteurs 100% XML!
http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

Le lundi 14 novembre 2005 à 10:52 +0100, Eric van der Vlist a écrit :

> IMO, this is bad from a user and designer point of view: URIs are
> important. I don't like web applications where the URI doesn't show what
> you're doing and I wouldn't want to deploy an application where all the
> edits are done through the same /orbeon/xforms-server-submit URI.

To be exhaustive, if one is interested only in what users see in the
navigation bar of their browsers, a workaround in to post to another
address:

<xforms:submission id="b" method="post" replace="all"
action="/sandbox/submit"/>

and to redirect this address to the location that you want users to see:

<page path-info="/sandbox/a" view="a.xhtml" id="a"/>
<page path-info="/sandbox/submit">
<action>
<result page="a" instance-passing="redirect"/>
</action>
</page>

that doesn't answer to my other points which are more architectural, but
that make them less visible to the end users!

Eric
--
Le premier annuaire des apiculteurs 100% XML!
http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

> The XForm submission defined as:
>
> <xforms:submission id="b" method="post" replace="all"
> action="/sandbox/a"/>
>
> Triggers a submission from the browser which is an HTTP POST with an
> "application/x-www-form-urlencoded" content to the address
> /orbeon/xforms-server-submit.

Correct.

> (There are other submissions to /orbeon/xforms-server but I guess
> that they are part of the Ajax exchanges necessary to support XML
> events.)

Correct.

> While serving this POST to /orbeon/xforms-server-submit, the server
> then behaves like if this request had been a POST of an XML document
> to /sandbox/a.

Kind of incorrect, see below.

> I don't want to be harsh, but I think that you just can't do that!

Cannot answer this, as I think there is some misunderstanding ;-)

> IMO, this is bad from a user and designer point of view: URIs are
> important. I don't like web applications where the URI doesn't show
> what you're doing and I wouldn't want to deploy an application where
> all the edits are done through the same /orbeon/xforms-server-submit
> URI.

Two different problems to consider:

1. What URI your browser shows. Here, ideally you either should find a
way of, at the same time:

a. Doing an XML POST directly from the web browser and
b. Use the resulting data stream to replace the current page

Or, POST to the URL, as you suggest below, not XML, but HTML
form-encoded data.

Note that you should also handle PUT, not only POST, in the end.

2. The fact that the XForms engine is in fact doing a POST of the
right data to the right URL and sending the appropriate response to
the web browser. This, I think, OPS clearly does correctly.

> Maybe more important, this isn't conform to the XForms
> recommendation.

Not true but I think there is a misunderstanding, see below.

> Now, I admit that the XForms specification doesn't say that an
> application can't be distributed between the client and the server,
> use an urlencoded-post between the client and the server and then
> performs an XML POST between the server part of the XForms
> implementation and an HTTP server.

Exactly.

> But still, there would need to be a POST of the XML instance
> document to be conform to the XForms recommendation and I don't
> think you can say that this POST is virtual and that you just
> simulate one.

But we do the POST. Here is maybe what you missed. The XForms
submission engine in OPS makes a distinction between two situations:

1. POST-ing to a URL which happens to be in the same webapp that runs
the application that generated the page. Here we optimize by doing
the POST at the Servlet API level, i.e. we create a Request which
looks exactly like a POST to the receiving Servlet. From the
receiving Servlet, there is in theory no way of seeing a
differenence between this and an actual HTTP POST.

2. POST-ing to a URL which does not satisfy the above. In this case,
we actually go through HTTP to perform the POST. This is clearly
less efficient.

> In other words, I think that to be conform to the XForms req, the
> POST to /orbeon/xforms-server-submit should perform a "physical" XML
> POST as described by the rec to /orbeon/sandbox/a. This would have
> the added benefit that you would support external URIs.

I hope the explanation above helps. Now maybe you would like to have
an option to completely disable optimization #1 above, and always use
HTTP. This is of course doable.

> If you really want to do what you're doing right now (which is
> probably more efficient), I think that you should define your own
> method in a specific namespace:
>
> <xforms:submission id="b" method="ops:pseudo-post" replace="all"
> action="/sandbox/a"/>

I think that there would be not point, as the receving application
sees the same POST with #1 and #2 above.

> Note that wouldn't solve by first point about the unique URI.

No, unfortunately it wouldn't: this only changes how the XFrorms
engine performs the POST, not what the user sees in his browser.

> About that first point, why couldn't the XForms server engine
> intercept urlencoded-post posts to every pages and not only
> /orbeon/xforms-server-submit?

> That was more or less what OPS 2.8 was doing, couldn't OPS 3.0
> continue to so?

We thought about that, and here you are right, that could still be a
possibility. There may be a good reason why we didn't do it
eventually, but I can't remember. Maybe because then not all
submissions are equal: some will show you a nice URL, some won't (the
ones that post to external URLs).

> In other words, I think that both:
>
> <xforms:submission id="b" method="urlencoded-post" action="/sandbox/a"/>
> and
> <xforms:submission id="b" method="ops:post" action="/sandbox/a"/>
>
> would be fine if they were triggering the page "/sandbox/a"...

> The last solution (and probably the best one) would be to do a real
> XML POST submission in Javascript from the browser... Maybe in a
> next version?

Can you even do that? Yes you can POST XML, but can you use the
returned content to replace the current page entirely?

> Eric (again, not wanting to be harsh but just constructive!)

Thanks. I think that at this point the bottom line is that in the case
your are doing a POST (or PUT) to a URL which happens to be handled by
OPS, we could not go through /orbeon/xforms-server-submit. This would
have the benefit of showing the correct POST URL in the user's
browser, while of course you would have to be aware that your browser
is in fact POST-ing something which is not what the recipient
eventually see, i.e. there is a proxy that modifies the POST in the
middle. In all other cases though, your browser will still show a POST
to /orbeon/xforms-server-submit, and in the case of external URLs
there is no way around it.

-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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

> Le lundi 14 novembre 2005 ? 10:52 +0100, Eric van der Vlist a ?crit :
>
>
>>IMO, this is bad from a user and designer point of view: URIs are
>>important. I don't like web applications where the URI doesn't show what
>>you're doing and I wouldn't want to deploy an application where all the
>>edits are done through the same /orbeon/xforms-server-submit URI.
>
>
> To be exhaustive, if one is interested only in what users see in the
> navigation bar of their browsers, a workaround in to post to another
> address:
>
> <xforms:submission id="b" method="post" replace="all"
> action="/sandbox/submit"/>
>
> and to redirect this address to the location that you want users to see:
>
> <page path-info="/sandbox/a" view="a.xhtml" id="a"/>
> <page path-info="/sandbox/submit">
> <action>
> <result page="a" instance-passing="redirect"/>
> </action>
> </page>
>
> that doesn't answer to my other points which are more architectural, but
> that make them less visible to the end users!

Correct, this is an option in some cases, although sometimes you still
want your browser to show a page which is the result of a POST, and/or
you don't have a way of doing the subsequent GET easily.

But note that if you can do the above, then you can often just do a
submission with replace="none" or replace="instance". Then your page
doesn't even have to reload, and your browser's URL doesn't change. This
is assuming of course you are handling all the dynamic aspects of your
page with XForms.

-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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

In reply to this post by Erik Bruchez

Le lundi 14 novembre 2005 à 11:48 +0100, Erik Bruchez a écrit :

> Eric van der Vlist wrote:
>
> > The XForm submission defined as:
> >
> > <xforms:submission id="b" method="post" replace="all"
> > action="/sandbox/a"/>
> >
> > Triggers a submission from the browser which is an HTTP POST with an
> > "application/x-www-form-urlencoded" content to the address
> > /orbeon/xforms-server-submit.
>
> Correct.
>
> > (There are other submissions to /orbeon/xforms-server but I guess
> > that they are part of the Ajax exchanges necessary to support XML
> > events.)
>
> Correct.
>
> > While serving this POST to /orbeon/xforms-server-submit, the server
> > then behaves like if this request had been a POST of an XML document
> > to /sandbox/a.
>
> Kind of incorrect, see below.
>
> > I don't want to be harsh, but I think that you just can't do that!
>
> Cannot answer this, as I think there is some misunderstanding ;-)

Good! I was pretty sure that you couldn't be as wrong as I first thought
you were :-) ...

> > IMO, this is bad from a user and designer point of view: URIs are
> > important. I don't like web applications where the URI doesn't show
> > what you're doing and I wouldn't want to deploy an application where
> > all the edits are done through the same /orbeon/xforms-server-submit
> > URI.
>
> Two different problems to consider:
>
> 1. What URI your browser shows. Here, ideally you either should find a
> way of, at the same time:
>
> a. Doing an XML POST directly from the web browser and
> b. Use the resulting data stream to replace the current page
>
> Or, POST to the URL, as you suggest below, not XML, but HTML
> form-encoded data.
>
> Note that you should also handle PUT, not only POST, in the end.

Yes, that would be really cool.

> 2. The fact that the XForms engine is in fact doing a POST of the
> right data to the right URL and sending the appropriate response to
> the web browser. This, I think, OPS clearly does correctly.
>
> > Maybe more important, this isn't conform to the XForms
> > recommendation.
>
> Not true but I think there is a misunderstanding, see below.
>
> > Now, I admit that the XForms specification doesn't say that an
> > application can't be distributed between the client and the server,
> > use an urlencoded-post between the client and the server and then
> > performs an XML POST between the server part of the XForms
> > implementation and an HTTP server.
>
> Exactly.
>
> > But still, there would need to be a POST of the XML instance
> > document to be conform to the XForms recommendation and I don't
> > think you can say that this POST is virtual and that you just
> > simulate one.
>
> But we do the POST. Here is maybe what you missed. The XForms
> submission engine in OPS makes a distinction between two situations:
>
> 1. POST-ing to a URL which happens to be in the same webapp that runs
> the application that generated the page. Here we optimize by doing
> the POST at the Servlet API level, i.e. we create a Request which
> looks exactly like a POST to the receiving Servlet. From the
> receiving Servlet, there is in theory no way of seeing a
> differenence between this and an actual HTTP POST.
>
> 2. POST-ing to a URL which does not satisfy the above. In this case,
> we actually go through HTTP to perform the POST. This is clearly
> less efficient.

Really? I realize that what made me think that this wasn't the case is
that when I use http://whatever.com as an action I get a blank page
showing /orbeon/xforms-server-submit as its address. That left me with
the (false) impression that the POST hadn't be performed! You should
raise instead an exception that would mention that this external URL
gave an error...

> > In other words, I think that to be conform to the XForms req, the
> > POST to /orbeon/xforms-server-submit should perform a "physical" XML
> > POST as described by the rec to /orbeon/sandbox/a. This would have
> > the added benefit that you would support external URIs.
>
> I hope the explanation above helps. Now maybe you would like to have
> an option to completely disable optimization #1 above, and always use
> HTTP. This is of course doable.

I think that this could be useful for some applications and that should
be easy enough to implement.

> > If you really want to do what you're doing right now (which is
> > probably more efficient), I think that you should define your own
> > method in a specific namespace:
> >
> > <xforms:submission id="b" method="ops:pseudo-post" replace="all"
> > action="/sandbox/a"/>
>
> I think that there would be not point, as the receving application
> sees the same POST with #1 and #2 above.

Except that the POST can be simulated, yes. The method (post vs
ops:post) could be what enables or disables this optimization.

> > Note that wouldn't solve by first point about the unique URI.
>
> No, unfortunately it wouldn't: this only changes how the XFrorms
> engine performs the POST, not what the user sees in his browser.
>
> > About that first point, why couldn't the XForms server engine
> > intercept urlencoded-post posts to every pages and not only
> > /orbeon/xforms-server-submit?
>
> > That was more or less what OPS 2.8 was doing, couldn't OPS 3.0
> > continue to so?
>
> We thought about that, and here you are right, that could still be a
> possibility. There may be a good reason why we didn't do it
> eventually, but I can't remember. Maybe because then not all
> submissions are equal: some will show you a nice URL, some won't (the
> ones that post to external URLs).

Yes, maybe.

> > In other words, I think that both:
> >
> > <xforms:submission id="b" method="urlencoded-post" action="/sandbox/a"/>
> > and
> > <xforms:submission id="b" method="ops:post" action="/sandbox/a"/>
> >
> > would be fine if they were triggering the page "/sandbox/a"...
>
> > The last solution (and probably the best one) would be to do a real
> > XML POST submission in Javascript from the browser... Maybe in a
> > next version?
>
> Can you even do that? Yes you can POST XML, but can you use the
> returned content to replace the current page entirely?

Now that you're asking the question, I have to admit that this isn't
obvious...

> > Eric (again, not wanting to be harsh but just constructive!)
>
> Thanks. I think that at this point the bottom line is that in the case
> your are doing a POST (or PUT) to a URL which happens to be handled by
> OPS, we could not go through /orbeon/xforms-server-submit. This would
> have the benefit of showing the correct POST URL in the user's
> browser, while of course you would have to be aware that your browser
> is in fact POST-ing something which is not what the recipient
> eventually see, i.e. there is a proxy that modifies the POST in the
> middle. In all other cases though, your browser will still show a POST
> to /orbeon/xforms-server-submit, and in the case of external URLs
> there is no way around it.

Yes, that's a good summary.

I was also wondering if you couldn't give more visibility to the web app
designers on the HTTP actions he wants to support.

That could be done through exposing the actions in the PFC through a
virtual document (maybe as exposed by the request generator, maybe
something higher level).

People could then define which type of HTTP request they want to serve
for each page.

Thanks,

Eric
--
Don't you think all these XML schema languages should work together?
http://dsdl.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

In reply to this post by Erik Bruchez

Le lundi 14 novembre 2005 à 11:57 +0100, Erik Bruchez a écrit :

.../...

> But note that if you can do the above, then you can often just do a
> submission with replace="none" or replace="instance". Then your page
> doesn't even have to reload, and your browser's URL doesn't change. This
> is assuming of course you are handling all the dynamic aspects of your
> page with XForms.

Can you elaborate on using replace="none" or replace="instance"?

>From what I see, with these values, the only post is
to /orbeon/xforms-server (there is no post to
to /orbeon/xforms-server-submit) and nothing seems to be reaching the
pages defined in my page flow...

How can I make the connection between the XForms submission and a
pipeline in my page flow?

Thanks,

Eric

--
Carnet web :
http://eric.van-der-vlist.com/blog?t=category&a=Fran%C3%A7ais
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

Eric van der Vlist wrote:

> Can you elaborate on using replace="none" or replace="instance"?
>
> From what I see, with these values, the only post is to
> /orbeon/xforms-server (there is no post to to
> /orbeon/xforms-server-submit) and nothing seems to be reaching the
> pages defined in my page flow...

Assuming here a method="post" attribute on the XForms submission.

The value of the "replace" attribute doesn't change the actual request
made by the XForms engine to the specified URL. It only impacts what
happens when a response is read.

If you want the result of an XForms submission to be a new page, then
you need the value "all" (or no "replace" attribute at all, which
defaults to "all"). In this case, submission occurs partly through
Ajax, partly through a final POST done on the client (which is related
to the discussion we had in the rest of this thread).

If you want to submit something and do not expect a result, then use
"none". If you want to submit something and obtain a new XForms
instance as a result, use "instance". In these cases, the page does
not reload in your browser: submission is done through Ajax.

> How can I make the connection between the XForms submission and a
> pipeline in my page flow?

The idea is very simple. Following the example set by the BizDoc NG
example, you use a submission like this:

<xforms:submission id="main-submission"
ref="instance('request-instance')" method="post" action="/bizdoc2"/>

This ends up POSTing an XML document to the path /bizdoc2 in your PFC:

<page id="summary" path-info="/bizdoc2"
model="../bizdoc/summary/summary-model.xpl"
view="summary/summary-view.xhtml">

The PFC helps you and, when it detects a POST of an XML document,
makes it available to actions, models and views specified on this
page. They can simply access the submitted XML document by accessing
their "instance" input. This can be done from XPL, XSLT, and static
XML files (through XInclude).

This is detailed in this section of the doc:

http://www.orbeon.com/ops/doc/reference-page-flow#xml-submission

-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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

Le lundi 14 novembre 2005 à 15:23 +0100, Erik Bruchez a écrit :

> Eric van der Vlist wrote:
>
> > Can you elaborate on using replace="none" or replace="instance"?
> >
> > From what I see, with these values, the only post is to
> > /orbeon/xforms-server (there is no post to to
> > /orbeon/xforms-server-submit) and nothing seems to be reaching the
> > pages defined in my page flow...
>
> Assuming here a method="post" attribute on the XForms submission.
>
> The value of the "replace" attribute doesn't change the actual request
> made by the XForms engine to the specified URL. It only impacts what
> happens when a response is read.
>
> If you want the result of an XForms submission to be a new page, then
> you need the value "all" (or no "replace" attribute at all, which
> defaults to "all"). In this case, submission occurs partly through
> Ajax, partly through a final POST done on the client (which is related
> to the discussion we had in the rest of this thread).

Yes.

> If you want to submit something and do not expect a result, then use
> "none". If you want to submit something and obtain a new XForms
> instance as a result, use "instance". In these cases, the page does
> not reload in your browser: submission is done through Ajax.

That's pretty handy!

> > How can I make the connection between the XForms submission and a
> > pipeline in my page flow?
>
> The idea is very simple. Following the example set by the BizDoc NG
> example, you use a submission like this:
>
> <xforms:submission id="main-submission"
> ref="instance('request-instance')" method="post" action="/bizdoc2"/>
>
> This ends up POSTing an XML document to the path /bizdoc2 in your PFC:
>
> <page id="summary" path-info="/bizdoc2"
> model="../bizdoc/summary/summary-model.xpl"
> view="summary/summary-view.xhtml">
>
> The PFC helps you and, when it detects a POST of an XML document,
> makes it available to actions, models and views specified on this
> page. They can simply access the submitted XML document by accessing
> their "instance" input. This can be done from XPL, XSLT, and static
> XML files (through XInclude).

That's what I had understood. The reason I am asking that is that I am
not able to make the following example work:

XForm's model:

<xforms:model>
<xforms:instance src="oxf:/sandbox/instance.xml" id="instance"/>
<xforms:bind nodeset="/instance/decimal" type="xs:decimal"/>
<xforms:submission id="b" method="post" replace="none" action="/sandbox/save"/>
</xforms:model>

Page flow:

<page path-info="/sandbox/a" view="a.xhtml"/>
<page path-info="/sandbox/save" model="save.xpl"/>

Save.xpl:

<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"
xmlns:ap="http://apiculteurs.info/ns/presentation/"
xmlns:pfc="http://www.orbeon.com/oxf/controller" xmlns:snoopy="http://dyomedea.com/snoopy/">
<p:param name="instance" type="input"/>
<p:processor name="oxf:url-serializer">
<p:input name="config">
<config>
<url>oxf:/sandbox/instance.xml</url>
</config>
</p:input>
<p:input name="data" href="#instance" debug="instance"/>
</p:processor>
</p:config>

The server behaves like if the page "/sandbox/save" was never reached:
the document "instance.xml" is never updated and there is no error
message of any type if save.xpl doesn't exist...

I have also tried calling save.xpl in an action instead than calling it
as a model without any visible difference...

What I have missed?

Thanks,

Eric

PS: I attach the source files for this example

> This is detailed in this section of the doc:
>
> http://www.orbeon.com/ops/doc/reference-page-flow#xml-submission
>
> -Erik
>
> pièce jointe document plein texte (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

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

sandbox.zip (3K) Download Attachment

Colin O'Brien

Re: Still missing something fundamental with XForms NG and a couple of comments

Hi Eric

On Nov 14, 2005, at 10:10 AM, Eric van der Vlist wrote:

> That's what I had understood. The reason I am asking that is that I am
> not able to make the following example work:
>
> XForm's model:
>
> <xforms:model>
> <xforms:instance src="oxf:/sandbox/instance.xml"
> id="instance"/>
> <xforms:bind nodeset="/instance/decimal"
> type="xs:decimal"/>
> <xforms:submission id="b" method="post" replace="none"
> action="/sandbox/save"/>
> </xforms:model>
>
> Page flow:
>
> <page path-info="/sandbox/a" view="a.xhtml"/>
> <page path-info="/sandbox/save" model="save.xpl"/>

That's because, if I understand it correctly, your action is, if you'll
pardon the expression, an action, and not a URL.
This is different from, say, cgi processing.

What you need in your Page flow is

<page path-info="/sandbox/a" view="a.xhtml">
<action when"/*/action = 'sandbox/save'" action="save.xpl"/>
</page>

It is similar to cgi in that a "proxy" is between the browser and your
code and does "stuff" for you before you receive the submission.

It's then up to you what happens next.
Redisplay a page with the same url as the original, or a different url
(using the result element on the page to "redirect" to the required
page).

Hope that helps
Colin

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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

Le lundi 14 novembre 2005 à 10:38 -0500, Colin O'Brien a écrit :

> Hi Eric
>
> On Nov 14, 2005, at 10:10 AM, Eric van der Vlist wrote:
>
> > That's what I had understood. The reason I am asking that is that I am
> > not able to make the following example work:
> >
> > XForm's model:
> >
> > <xforms:model>
> > <xforms:instance src="oxf:/sandbox/instance.xml"
> > id="instance"/>
> > <xforms:bind nodeset="/instance/decimal"
> > type="xs:decimal"/>
> > <xforms:submission id="b" method="post" replace="none"
> > action="/sandbox/save"/>
> > </xforms:model>
> >
> > Page flow:
> >
> > <page path-info="/sandbox/a" view="a.xhtml"/>
> > <page path-info="/sandbox/save" model="save.xpl"/>
>
> That's because, if I understand it correctly, your action is, if you'll
> pardon the expression, an action, and not a URL.

Sure.

I have also tried (without any success):

<page path-info="/sandbox/save">
<action action="save.xpl"/>
</page>

which is IMO cleaner than using the model attribute.

> This is different from, say, cgi processing.
>
> What you need in your Page flow is
>
> <page path-info="/sandbox/a" view="a.xhtml">
> <action when"/*/action = 'sandbox/save'" action="save.xpl"/>
> </page>

You mean that OPS 3.0 would keep the same principle here than OPS 2.8?

That wouldn't work for me! I have no "action" element in my instance and
I don't want to have one :-) ... This /form/action hack was needed in
2.8 to workaround the limitations of the old XForms engine and it
shouldn't be necessary any longer!

In my XForms model, I differentiate the submissions by their locations,
why wouldn't the PFC take advantage of this?

Also, I have tried to adapt your suggestion by writing:

<page path-info="/instance" view="a.xhtml">
<action when="/instance" action="save.xpl"/>
</page>

That should differentiate the case when I have an instance that is
"null" and the case where I have my "real" instance which root element
is "instance" and that doesn't seem to be working any better than my
previous attempts!

Thanks,

Eric

--
Have you ever thought about unit testing XSLT templates?
http://xsltunit.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Colin O'Brien

Re: Still missing something fundamental with XForms NG and a couple of comments

Hi Eric

well, I did say my understanding might be limited.
I also didn't check my Xforms example, just my page flow.

In the code I suggested to you, I took the page/action/@when from your
XForms snippet.
Of course, the action you had was indeed for a url, and the action that
the page/action/@when reacts to is an attribute of the submission.

So going back your original example, I should have rewritten your
XForms model as
<xforms:model>
<xforms:instance src="oxf:/sandbox/instance.xml"
id="instance"/>
<xforms:bind nodeset="/instance/decimal" type="xs:decimal"/>
<xforms:submission id="b" method="post" replace="none"
action="/sandbox/a"/>
</xforms:model>

In my test form, derived I suspect like yours from the XForms sandbox
example, I do then have a trigger/action/setvalue
ref="action">save</setvalue><send submission="send"/> construct. And
yes, I do have an action element in my instance (and I wish I didn't).

In an exchange last week, I commented on extraneous data appearing on
my result URL and Erik repllied I was doing something to cause the 2.8
engine to be used.
So maybe this is it?
(But like I say, this is how the XForms Sandbox example is coded, and
it is tagged as NG).

In which case you have helped show me where my problem is, but I have
obviously not answered yours!

Colin

On Nov 14, 2005, at 11:03 AM, Eric van der Vlist wrote:

> Le lundi 14 novembre 2005 à 10:38 -0500, Colin O'Brien a écrit :
>> Hi Eric
>>
>> On Nov 14, 2005, at 10:10 AM, Eric van der Vlist wrote:
>>
>>> That's what I had understood. The reason I am asking that is that I
>>> am
>>> not able to make the following example work:
>>>
>>> XForm's model:
>>>
>>> <xforms:model>
>>> <xforms:instance src="oxf:/sandbox/instance.xml"
>>> id="instance"/>
>>> <xforms:bind nodeset="/instance/decimal"
>>> type="xs:decimal"/>
>>> <xforms:submission id="b" method="post" replace="none"
>>> action="/sandbox/save"/>
>>> </xforms:model>
>>>
>>> Page flow:
>>>
>>> <page path-info="/sandbox/a" view="a.xhtml"/>
>>> <page path-info="/sandbox/save" model="save.xpl"/>
>>
>> That's because, if I understand it correctly, your action is, if
>> you'll
>> pardon the expression, an action, and not a URL.
>
> Sure.
>
> I have also tried (without any success):
>
> <page path-info="/sandbox/save">
> <action action="save.xpl"/>
> </page>
>
> which is IMO cleaner than using the model attribute.
>
>
>> This is different from, say, cgi processing.
>>
>> What you need in your Page flow is
>>
>> <page path-info="/sandbox/a" view="a.xhtml">
>> <action when"/*/action = 'sandbox/save'" action="save.xpl"/>
>> </page>
>
> You mean that OPS 3.0 would keep the same principle here than OPS 2.8?
>
> That wouldn't work for me! I have no "action" element in my instance
> and
> I don't want to have one :-) ... This /form/action hack was needed in
> 2.8 to workaround the limitations of the old XForms engine and it
> shouldn't be necessary any longer!
>
> In my XForms model, I differentiate the submissions by their locations,
> why wouldn't the PFC take advantage of this?
>
> Also, I have tried to adapt your suggestion by writing:
>
> <page path-info="/instance" view="a.xhtml">
> <action when="/instance" action="save.xpl"/>
> </page>
>
> That should differentiate the case when I have an instance that is
> "null" and the case where I have my "real" instance which root element
> is "instance" and that doesn't seem to be working any better than my
> previous attempts!
>
> Thanks,
>
> Eric
>
> --
> Have you ever thought about unit testing XSLT templates?
>
> http://xsltunit.org
> -----------------------------------------------------------------------
> -
> Eric van der Vlist http://xmlfr.org
> http://dyomedea.com
> (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
> (W3C) XML Schema ISBN:0-596-00252-1
> http://oreilly.com/catalog/xmlschema
> -----------------------------------------------------------------------
> -
>
>
>
> --
> 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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

>> Note that you should also handle PUT, not only POST, in the end.
>
> Yes, that would be really cool.

Not sure if that comment applied to the question of "PUT", but I
notice that PUT is not allowed by the HTML 4 spec. Still, in case we
"virtualize" the POST or PUT with the only purpose of putting a nice
URL in the browser bar, we could always do a POST, and the middle man
(the PFC) can switch it to PUT.

>>2. POST-ing to a URL which does not satisfy the above. In this case,
>> we actually go through HTTP to perform the POST. This is clearly
>> less efficient.
>
>
> Really? I realize that what made me think that this wasn't the case
> is that when I use http://whatever.com as an action I get a blank
> page showing /orbeon/xforms-server-submit as its address. That left
> me with the (false) impression that the POST hadn't be performed!
> You should raise instead an exception that would mention that this
> external URL gave an error...

I just tried to modify my local BizDoc NG's summary page to point to
the online Orbeon PresentationServer install:

<xforms:submission id="main-submission" ref="instance('request-instance')"
method="post" action="http://www.orbeon.com/ops/bizdoc2"/>

and I get the correct result. So it looks like if it doesn't work,
it's likely to be because an error is occurring. Error handling upon
submission in this case is actaully a funny one, because the spec
says:

"For an error response nothing in the document is replaced, and submit
processing concludes after dispatching xforms-submit-error."

So in theory, you would only get that event dispatched, not a nice
error message.

Now I have to reckon that there is a problem: because the POST is
underway and the web browser has itself performed a POST, the web page
is no longer "alive" to receive the xform-submit-error event... I see
two solutions:

1. Not implement the spec (or provide an optional behavior), and when
doing a POST with replace="all" with error, propagate the Java
exception to the client.

2. Perform the actual POST during the Ajax submission. This allows
detecting errors and dispatching the xforms-submit-error
event. However, this also means that the server must:

a. buffer the response
b. tell the client to do its POST
c. serve the buffered response to the client

#b and #c are already done now, but #a has performance drawbacks.

This said I think the current behavior is not very good. So we should
have an option:

1. More optimal but less compliant mode, where submission errors
cannot be caught by the XForms engine (note that this only concerns
replace="all"; for replace="instance" or replace="none", errors can
be caught).

2. Less optimal but more compliant mode, where the replacement page is
buffered on the server. This allows catching submission errors in
all cases.

RFE:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304288&group_id=168&atid=350210

> I think that this could be useful for some applications and that
> should be easy enough to implement.

Part of the RFE above is now implemented (the XForms-compliance mode
with buffering is not). The "Optimize Post All" mode now throws an
exception if something wrong happens after connecting to the
submission URL. You will see that exception in your browser.

>>I think that there would be not point, as the receving application
>>sees the same POST with #1 and #2 above.
>
>
> Except that the POST can be simulated, yes. The method (post vs
> ops:post) could be what enables or disables this optimization.

Possibly, yes. The only drawback I see is that then you have to
explain this option to users. I am leaning toward optimizing by
default. At any rate I entered and implemented the following RFE:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304289&group_id=168&atid=350210

>>Thanks. I think that at this point the bottom line is that in the case
>>your are doing a POST (or PUT) to a URL which happens to be handled by
>>OPS, we could not go through /orbeon/xforms-server-submit. This would
>>have the benefit of showing the correct POST URL in the user's
>>browser, while of course you would have to be aware that your browser
>>is in fact POST-ing something which is not what the recipient
>>eventually see, i.e. there is a proxy that modifies the POST in the
>>middle. In all other cases though, your browser will still show a POST
>>to /orbeon/xforms-server-submit, and in the case of external URLs
>>there is no way around it.
>
>
> Yes, that's a good summary.

I created an RFE for this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304290&group_id=168&atid=350210

It should actually be fairly easy to implement, as this part is
currently controlled by an XPL pipeline,
xforms-xml-submission.xpl. The other side of things is making the
XForms server tell the client to POST to a different URL.

> I was also wondering if you couldn't give more visibility to the web app
> designers on the HTTP actions he wants to support.
>
> That could be done through exposing the actions in the PFC through a
> virtual document (maybe as exposed by the request generator, maybe
> something higher level).
>
> People could then define which type of HTTP request they want to serve
> for each page.

Wouldn't specifying what method is allowed for a page be enough?

-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

Eric van der Vlist

Re: Still missing something fundamental with XForms NG and a couple of comments

Le lundi 14 novembre 2005 à 18:39 +0100, Erik Bruchez a écrit :
> Eric van der Vlist wrote:
>
> >> Note that you should also handle PUT, not only POST, in the end.
> >
> > Yes, that would be really cool.
>
> Not sure if that comment applied to the question of "PUT",

Yes, it did.

> but I
> notice that PUT is not allowed by the HTML 4 spec.

No, PUT (and DELETE) were initially meant to be but web apps rather than
for browsers. Now, they tend to become more common (PUT for instance
seems to be the right method to use to update a blog entry).

> Still, in case we
> "virtualize" the POST or PUT with the only purpose of putting a nice
> URL in the browser bar, we could always do a POST, and the middle man
> (the PFC) can switch it to PUT.

Yes, exactly.

> >>2. POST-ing to a URL which does not satisfy the above. In this case,
> >> we actually go through HTTP to perform the POST. This is clearly
> >> less efficient.
> >
> >
> > Really? I realize that what made me think that this wasn't the case
> > is that when I use http://whatever.com as an action I get a blank
> > page showing /orbeon/xforms-server-submit as its address. That left
> > me with the (false) impression that the POST hadn't be performed!
> > You should raise instead an exception that would mention that this
> > external URL gave an error...
>
> I just tried to modify my local BizDoc NG's summary page to point to
> the online Orbeon PresentationServer install:
>
> <xforms:submission id="main-submission" ref="instance('request-instance')"
> method="post" action="http://www.orbeon.com/ops/bizdoc2"/>
>
> and I get the correct result. So it looks like if it doesn't work,
> it's likely to be because an error is occurring. Error handling upon
> submission in this case is actaully a funny one, because the spec
> says:
>
> "For an error response nothing in the document is replaced, and submit
> processing concludes after dispatching xforms-submit-error."
>
> So in theory, you would only get that event dispatched, not a nice
> error message.
>
> Now I have to reckon that there is a problem: because the POST is
> underway and the web browser has itself performed a POST, the web page
> is no longer "alive" to receive the xform-submit-error event... I see
> two solutions:
>
> 1. Not implement the spec (or provide an optional behavior), and when
> doing a POST with replace="all" with error, propagate the Java
> exception to the client.
>
> 2. Perform the actual POST during the Ajax submission. This allows
> detecting errors and dispatching the xforms-submit-error
> event. However, this also means that the server must:
>
> a. buffer the response
> b. tell the client to do its POST
> c. serve the buffered response to the client
>
> #b and #c are already done now, but #a has performance drawbacks.
>
> This said I think the current behavior is not very good. So we should
> have an option:
>
> 1. More optimal but less compliant mode, where submission errors
> cannot be caught by the XForms engine (note that this only concerns
> replace="all"; for replace="instance" or replace="none", errors can
> be caught).
>
> 2. Less optimal but more compliant mode, where the replacement page is
> buffered on the server. This allows catching submission errors in
> all cases.
>
> RFE:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=304288&group_id=168&atid=350210
>
> > I think that this could be useful for some applications and that
> > should be easy enough to implement.
>
> Part of the RFE above is now implemented (the XForms-compliance mode
> with buffering is not). The "Optimize Post All" mode now throws an
> exception if something wrong happens after connecting to the
> submission URL. You will see that exception in your browser.
>
> >>I think that there would be not point, as the receving application
> >>sees the same POST with #1 and #2 above.
> >
> >
> > Except that the POST can be simulated, yes. The method (post vs
> > ops:post) could be what enables or disables this optimization.
>
> Possibly, yes. The only drawback I see is that then you have to
> explain this option to users. I am leaning toward optimizing by
> default. At any rate I entered and implemented the following RFE:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=304289&group_id=168&atid=350210
>
> >>Thanks. I think that at this point the bottom line is that in the case
> >>your are doing a POST (or PUT) to a URL which happens to be handled by
> >>OPS, we could not go through /orbeon/xforms-server-submit. This would
> >>have the benefit of showing the correct POST URL in the user's
> >>browser, while of course you would have to be aware that your browser
> >>is in fact POST-ing something which is not what the recipient
> >>eventually see, i.e. there is a proxy that modifies the POST in the
> >>middle. In all other cases though, your browser will still show a POST
> >>to /orbeon/xforms-server-submit, and in the case of external URLs
> >>there is no way around it.
> >
> >
> > Yes, that's a good summary.
>
> I created an RFE for this:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=304290&group_id=168&atid=350210
>
> It should actually be fairly easy to implement, as this part is
> currently controlled by an XPL pipeline,
> xforms-xml-submission.xpl. The other side of things is making the
> XForms server tell the client to POST to a different URL.
>
> > I was also wondering if you couldn't give more visibility to the web app
> > designers on the HTTP actions he wants to support.
> >
> > That could be done through exposing the actions in the PFC through a
> > virtual document (maybe as exposed by the request generator, maybe
> > something higher level).
> >
> > People could then define which type of HTTP request they want to serve
> > for each page.
>
> Wouldn't specifying what method is allowed for a page be enough?

Short term, when we have only GET and POST, yes probably but longer
term, if we add PUT and DELETE, it seems necessary to define different
actions depending on the method: I wouldn't want my delete treated like
a GET :-) ...

Thanks for the very detailed explanations and sorry to be so
troublesome!

OPS 3.0 is still more stunning than I thought before starting using the
new XForms engine. The gap with OPS 2.8 is really impressive and one has
to forget a lot of what he/she might have learned!

Eric

--
If you have a XML document, you have its schema.
http://examplotron.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

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

Colin O'Brien

Re: Still missing something fundamental with XForms NG and a couple of comments

In reply to this post by Colin O'Brien

Thinking about this some more

On Nov 14, 2005, at 11:43 AM, Colin O'Brien wrote:

> In my test form, derived I suspect like yours from the XForms sandbox
> example, I do then have a trigger/action/setvalue
> ref="action">save</setvalue><send submission="send"/> construct. And
> yes, I do have an action element in my instance (and I wish I didn't).

I realize that I really do benefit from having the action in my
instance, since then it (knowing which button the user clicked) is
available for testing in my code.

(I was just saying I wish I didn't because in my current test example,
I only had the one button, so I wasn't interested in knowing, and I had
to write code to exclude it from the save to the file system that I did
subsequently).

Oh well.

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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

>>If you want to submit something and do not expect a result, then use
>>"none". If you want to submit something and obtain a new XForms
>>instance as a result, use "instance". In these cases, the page does
>>not reload in your browser: submission is done through Ajax.
>
>
> That's pretty handy!

I would say it's more than that! It's really one of the strongest and
coolest features of XForms. You can call XML services this way. The WG
is (at least was) also discussing helping make SOAP calls using the
XForms submission. At any rate, this opens many possibilities very
much in line with what people are looking for in Ajax.

> That's what I had understood. The reason I am asking that is that I am
> not able to make the following example work:

> The server behaves like if the page "/sandbox/save" was never reached:
> the document "instance.xml" is never updated and there is no error
> message of any type if save.xpl doesn't exist...
>
> I have also tried calling save.xpl in an action instead than calling it
> as a model without any visible difference...
>
> What I have missed?

I don't know for sure, because I ran your code, and it appears to be
working. The instance is saved on disk :-)

But this is what I think is happening:

o You must have some error occurring when runing save.xpl. If that's
the case, you should see an exception in your logs.

o Because of the "optimized" local submission, in the particular case
of replace"none", we use the Servlet API's include() method. And
what do I read in the spec: "The target servlet of the include
method [...] cannot set headers or call any method that affects the
headers of the response. Any attempt to do so must be ignored." So
we don't catch that error.

o Therefore, we send the xforms-submission-done event, as if
everything had been fine. here is a case where this optimized
submission should probably not be used... With the new option to
turn off this optimized submission in place, it works, and the error
is caught.

o But in general, the XForms server fires an xforms-submit-error
event, which you can catch, for example with:

<xforms:instance id="status">
<message xmlns=""/>
</xforms:instance>

<xforms:submission id="b" method="post" replace="none"
action="/evdv3/save">
<xforms:setvalue ev:event="xforms-submit-error"
ref="instance('status')">Submission failed!</xforms:setvalue>
<xforms:setvalue ev:event="xforms-submit-done"
ref="instance('status')">Submission succeeded!</xforms:setvalue>
</xforms:submission>


Status: <xforms:output ref="instance('status')"/>


What resource manager are you using? What happens if you use a "file:"
scheme instead of an "oxf:" scheme with the URL serializer? The
problem is probably linked to the issue you mentioned in another
thread with the URL serializer.

-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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Colin O'Brien

Colin O'Brien wrote:

> That's because, if I understand it correctly, your action is, if you'll
> pardon the expression, an action, and not a URL.
> This is different from, say, cgi processing.
>
> What you need in your Page flow is
>
> <page path-info="/sandbox/a" view="a.xhtml">
> <action when"/*/action = 'sandbox/save'" action="save.xpl"/>
> </page>
>
> It is similar to cgi in that a "proxy" is between the browser and your
> code and does "stuff" for you before you receive the submission.
>
> It's then up to you what happens next.
> Redisplay a page with the same url as the original, or a different url
> (using the result element on the page to "redirect" to the required page).

You are correct that you can use <action> in this case, and that it does
in fact look and sound better, however Eric's use of a "model" attribute
would technically work just as well.

-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

Erik Bruchez

Re: Still missing something fundamental with XForms NG and a couple of comments

Administrator

In reply to this post by Eric van der Vlist

Eric van der Vlist wrote:

>>Wouldn't specifying what method is allowed for a page be enough?
>
>
> Short term, when we have only GET and POST, yes probably but longer
> term, if we add PUT and DELETE, it seems necessary to define
> different actions depending on the method: I wouldn't want my delete
> treated like a GET :-) ...
>
> Thanks for the very detailed explanations and sorry to be so
> troublesome!

Thank you! You had several quite relevant points that warranted RFEs
and fixes, and this is all for the good of Orbeon PresentationServer.

> OPS 3.0 is still more stunning than I thought before starting using
> the new XForms engine. The gap with OPS 2.8 is really impressive and
> one has to forget a lot of what he/she might have learned!

Thanks, and yes, there are a few things to be forgotten ;-)

-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