Re: url params et al

Jason,

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

You're not going mad...it's not possible! It's a very interesting
problem though. The same question came up recently in our formsPlayer
lists, and it also came up for us a year or so ago in some work for a
customer.

There are a number of ways you could look at this, with varying
amounts of generality. At one end of the spectrum, I'm afraid you'll
have to put the form into something dynamic like PHP, JSP, ASP, etc.
That's what we did for the customer a few years ago, so their ASP form
looked something like this:

  .
  .
  .
  <xf:instance id="inst-user">
    <profile>
      <user><%=userid%></user>
      <state><%=workflowstate%></state>
    </profile>
  </xf:instance>
  .
  .
  .

Then, on xforms-ready we did a submission to go get the current state
of the workflow for a particular user.

The really annoying thing about this solution--as you have also
realised--is that you go from having nice, generic XForms documents
that could run on any server, to very specific documents written with
(in our customers case) ASP, all for the sake of two lines of
server-side script.

The next possibility is to store the data needed on the users'
machines and then pick it up in the subsequent form. Once you have the
data you can perform the same submission. In formsPlayer this involves
using the "cookie:" protocol to save instance data in a per user/per
site area. But of course, that's formsPlayer only. An example of the
protocol in use is available here:

  <http://skimstone.x-port.net/node/203>

So, we have a server-specific solution, or a client-specific
solution...but still no generic one!

An idea we're looking at for our Sidewinder Viewer is the notion of
'client-side parameters'. Currently you can pass parameters to a
server-side application like this:

  http://example.com/x.jsp?a=b

and you can pass parameters to a client-side application like this:

  swviewer.exe http://example.com/x.jsp

But you can't pass parameters to the web app itself. We're planning to
do something like this:

  http://example.com/x.jsp?a=b#param(userid=7,workflowstate=19)

This would provide a list of variables to the web app, much like you
get during XSLT processing. At the moment our idea is that we would
make use of these parameters using the XSLT syntax:

  .
  .
  .
  <xf:instance id="inst-user">
    <profile>
      <user>{$userid}</user>
      <state>{$workflowstate}</state>
    </profile>
  </xf:instance>
  .
  .
  .

A downside of this 'squiggly bracket' syntax is that it might not be
that easy to implement in current browsers, which is a shame, since it
would be very easy to write some script that parses the URL to pull
out the parameters. Perhaps an additional set of functionality might
be to indicate where in the document to place the parameters, so that
once the URL has been parsed the values are just 'poked' in.

Regards,

Mark

-- 
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 11:08:28 UTC