Re: url params et al

another way to look at this would be to think of the session
specific params as living in an XML file.

Then turn xforms on its head and use an xhtml+xforms document as
the edit template for that XML document, and on load have that
document do a submit with replace=instance to act as a
"bootstrap" step to pull in the rest of the session-specific
data.

We in the XForms WG had discussed this as an XML-EDit PI at one
point but never finished it --- but you could probably get there
by just viewing the xhtml+xforms template as a viewing lens or a
"transform" in this case.

Mark Birbeck writes:
 > 
 > 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/

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman

Received on Wednesday, 23 August 2006 16:51:02 UTC