RE: url params et al

Please note in Section 11.2 of the XForms spec 
(http://www.w3.org/TR/2006/REC-xforms-20060314/slice11.html#submit-options)
that the get and put methods include the file scheme.

Hence, local save and reload can be accomplished using the file: scheme of 
an XForms submission in combination
with the replace="instance" setting of the submission.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Francisco Monteiro" <monterro2004@tiscali.co.uk> 
Sent by: www-forms-request@w3.org
08/23/2006 07:27 AM

To
<www-forms@w3.org>
cc

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