RE: url params et al

Mark,
You make good points about future directions...the current state and its
logical parititioning is what I described.
Leigh. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Wednesday, August 23, 2006 10:27 AM
To: www-forms@w3.org
Subject: Re: url params et al


Leigh,

> I think this processing rightfully belongs on the server, as the URI
> specifies the resource, and the server is responsible for providing
you
> the resource.

But you don't know what the resource is until you construct it...and
that construction doesn't belong on the server.


> I'm not sure what XForms processor you're using, but in browsers that
> support JavaScript handlers, you can ask the browser what the page URI
> was (via the location property).

That's what I am suggesting...but that's the easy bit. What we don't
have is a *standard* way to put the values we want into the URL.

Take something like Slidey, the W3C's HTML presentation viewer, which
uses script to take an ordinary HTML document and make it behave like
a presentation. You can give someone a URL which will take them to a
specific slide, like this:

  http://skimstone.x-port.net/files/rdfa-slides.html#(18)

and as you rightly say it's no big deal to extract the fragment
identifier and use it as a parameter. But unfortunately that's only
one parameter, and we might need more. And we also might want to name
the paramaters, in the same way that we do when passing parameters to
the server. So my suggestion was to have a standardised syntax for
client-side parameters in HTML documents, along the lines of:

  http://skimstone.x-port.net/files/rdfa-slides.html#param(slide=18)

When this technique is applied to XForms, it means we can have forms
that are delivered from the server that require no server-side
processing, meaning they are independent of any particular server
software. Of course we will need server-side processing for other
things, but with this technique you can reserve that processing for
the generation and handling of the instance data (which if you use
REST/SOAP/XQuery, etc., you once again remove any dependence on a
particular set of software, like ASP, PHP, JSP, etc.).

Regards,

Mark
>
>
> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> Behalf Of Jason
> Sent: Tuesday, August 22, 2006 11:46 PM
> To: www-forms@w3.org
> Subject: url params et al
>
>
> Hi all -I think I'm going quietly mad. I have a small problem that I
> haven't had to deal with via xforms before (I think) and cant seem to
> see the solution - it must be easy, I'm sure of it.
> I need to launch an xform with a given data id passed as an url
> parameter (the url will come from an email). eg:
> http://.../somexform?id=abcd
>
> the form then needs to load data with id=abcd (or at least something
> derived from it).
>
> my question is how can I do this without dynamically modifying the
xform
>
> itself each time. I dont really want to store the id in a session
> variable and have the form retrieve it on form-ready, I'd like to know
> if its possible with a pure xform, or at least a nicer approach to
this
> one. This would be trivial if the initial request was via the xform,
but
>
> how do you preset a forms' state for startup without having the form
> request the info itself?
>
> any thoughts? I think my head must be full of cotton wool.
>
> thanks
> Jason.
>
>
>
>
>


-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Wednesday, 23 August 2006 17:35:00 UTC