RE: url params et al

 Jason,

One of the requirements for Xforms should be a save/restore locally, 
Take a look at this
http://showoff2.awardspace.biz/pack/pack/examples/recovery.html

The dojo flash solution is far more flexible, try the above URL
Cycle the next button when you want hit the "reload" button, the form should
be where you last left it.

There is "actually" no storage limit, Xforms can be designed so much
differently when you have this kind of flexibility. Firefox 2.0 will have
this local storage natively in 2.0 flash is 98% available today. We are
doing a pilot study for a very large company as part of the "Web Application
Design" stream, which I am even more confused on what it's aims are!

Somebody explain me what is Web Forms 2.0?

Francisco



-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Birbeck
Sent: 23 August 2006 12:08
To: www-forms@w3.org
Subject: 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/