- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 22 Jun 2004 15:17:00 +0100
- To: <www-forms@w3.org>
Bryan, Although what you say is true, I wonder if Dharmesh is actually after some way of returning to data later on. As the XForms specification stands the 'many instances' approach requires that you have one big form that has all possible 'sub-forms' that need to share the same instance data. An example is something like the salesforce.com CRM web services, which give users a session ID when they log on. This session ID is needed for each subsequent request to the server, and there is currently no standard way to pass this data from one form to another, without passing it up to some server, and then back again as part of a new form. (There are *non-standard* ways to do this in formsPlayer, and I'm sure there are in other processors - but of course, we're all concerned with standards ;).) This is something that I have been keen on for quite a while, so I'd like to hear any thoughts and feedback people have. Currently I see three ways that we could approach this (not all mutually exclusive). The first is already implemented by some processors. 1. DEFAULT FILE LOCATION In formsPlayer (and I believe X-Smiles), if you save or load a file from a *relative* path with the "file" protocol: <instance src="file:my-config.xml" /> and the document was not loaded with the "file" protocol (for example, via HTTP), the file will be read from or saved to a 'per-user' location. In formsPlayer this is to the desktop. This is partly because you need to make some decision as to where things should go, since there is no definition of how to work out the absolute value of a relative URI if it's 'relative' to a URI from a different protocol. Since I'm pretty sure that X-Smiles does something similar to us (not to the desktop, but to a user-specific location) this would give some level of interoperability. Of course, security concerns mean that in formsPlayer we've had to show an annoying dialog box, so we're trying to work on this. 2. DYNAMIC URLs The second way this could be done is by allowing @action on <submission> to hold an XPath query. This would allow you to set the location for each user and application. This is of course not supported in XForms 1.0, although is 'in the air' for a future version. It is supported in formsPlayer via the xforms:extension element, but of course that makes it non-standard. 3. A 'COOKIE' PROTOCOL Even if either of the first two solutions were available on all XForms processors, the 'file' protocol shouldn't be trusted. I'd therefore be quite interested to see a way of expressing some 'known per-user location' via a URL. That way we could effectively create 'XML cookies': <instance src="cookies://my-config.xml" /> We could define 'cookies:' as going to some file location on a per user, per domain basis, much like cookies do now. This could even work on mobile devices, since the cookie location could be mapped to a server. This last approach is my preferred one, and note that it would not need to be part of the XForms specification. Any thoughts? Regards, Mark Mark Birbeck CEO and CTO x-port.net Ltd. Download our XForms processor from http://www.formsPlayer.com/ -----Original Message----- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com> Date: Tue, 22 Jun 2004 06:33:27 -0400 Message-Id: <D24D16A6707B0A4B9EF084299CE99B39103DFB3B@mcl-its-exs02.mail.saic.com> To: Dharmesh Mistry <dharmesh@edgeipk.com>, www-forms@w3.org Yes. An XForms client can hold multiple XML trees as instance data. It is my understanding that these data either survive a submission (and so are held by the client), or that at most one XML instance data section is replaced after a successful submission (the one whose data was submitted), or that the entire page is replaced (normal HTML Forms-based navigation). The first and second of these cases are responsive to your request. They behavior is controlled by the "replace" attribute on the "submission" element. -bryan -----Original Message----- From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Dharmesh Mistry Sent: Tuesday, June 22, 2004 4:12 AM To: www-forms@w3.org Subject: Client Side Session management We have been deploying web applications for a number of years now. Where possible we have adopted standards, how for transactional web based applications we have had to question the standard "CGI" model. One thing we think that would be of massive benefit is client side session data (more than just cookies) support. Such that data can be held in the memory of the client. This would enable not having to write code to repopulate forms. Also would overcome the constant issue of Browser back buttons picking up cached forms (which then have to be expired so the server can represent the data).
Received on Tuesday, 22 June 2004 10:17:10 UTC