bkyle / ubiquity-xforms

Automatically exported from code.google.com/p/ubiquity-xforms
0 stars 0 forks source link

Separator for resource and GET params #288

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
On a www-url-encoded submission (e.g. a GET), we currently put
a ? between the resource URI and the params.
But if the resource URI already contains a ?, then we are not supposed to
use a question mark.
If the question mark is anywhere but the end, we must add the 
submission separator (usu. an ampersand, but should use oBody.separator).

For the replace all case, more work is needed because the code seems to 
ignore extra params in the resource URI, so the extra params need to be
added to oBody.dictionary and then just supply the resource URI without
the ? and extra params (if any).

Also, in some of the above cases, current code is modifying the sResource,
which is inappropriate because if there is an xforms-submit-error, the
resource-uri parameter should contain the unmodified resource
(double check spec).

Finally, another test suite form should be added into the "revised" test 
area.

Original issue reported on code.google.com by John.Boyer.PhD@gmail.com on 1 Mar 2009 at 11:40

GoogleCodeExporter commented 8 years ago
I think there might be one more case to look at though. Whilst you are right 
that
adding this:

  c=3&d=4

to this:

  http://mysite.com?a=1&b=2

should give this:

  http://mysite.com?a=1&b=2&c=3&d=4

I'm wondering what is supposed to happen if there is a fragment identifier; I 
would
expect this:

  http://mysite.com?a=1&b=2#z

to yield this:

  http://mysite.com?a=1&b=2&c=3&d=4#z

and NOT this:

  http://mysite.com?a=1&b=2#z&c=3&d=4

Also, if there is an empty query string, I don't think we want a leading 
ampersand,
i.e., if we have this:

  http://mysite.com?

I don't think we want this:

  http://mysite.com?&c=3&d=4

It may sound like a lot of checks to be done, but actually the easiest way to 
do this
is to:

* break the first URL open, into its component parts;
* add the query parameters to the query section;
* reassemble the URL.

I say 'easy' because the Ubiquity Backplane URI module has all of the routines 
needed
to do this, because it's a key part of the RDFa parser to be able to manage URIs
flexibily.

So I'm happy to take on this issue and incorporate the library.

(Incorporating the library simply means making a reference to the correct 
module in
the loader.)

Original comment by mark.bir...@gtempaccount.com on 7 Mar 2009 at 1:46

GoogleCodeExporter commented 8 years ago

Original comment by John.Boyer.PhD@gmail.com on 13 Mar 2009 at 6:36

GoogleCodeExporter commented 8 years ago

Original comment by John.Boyer.PhD@gmail.com on 24 Mar 2009 at 5:01

GoogleCodeExporter commented 8 years ago
As I said in comment 1, the easiest way to do this is to use the URI routines 
from the Backplane library, so I've 
added a dependency here.

Original comment by mark.bir...@gtempaccount.com on 24 Aug 2009 at 12:34

GoogleCodeExporter commented 8 years ago
Added code in r3247 to fix this issue, pending review.

Original comment by John.Boyer.PhD@gmail.com on 17 Jan 2010 at 11:25

GoogleCodeExporter commented 8 years ago
Revised fix at r3253

Original comment by John.Boyer.PhD@gmail.com on 22 Jan 2010 at 10:48

GoogleCodeExporter commented 8 years ago
Further revised solution at r3263, Fixed by trunk commit r3264

Original comment by John.Boyer.PhD@gmail.com on 30 Jan 2010 at 12:47