- From: Avi Bryant <avi@beta4.com>
- Date: Wed, 16 Jun 2004 11:42:55 -0700
On Jun 16, 2004, at 9:32 AM, Mikko Rantalainen wrote: > 1) OK, I can almost "solve" this one with CSS but still, why not add > new attribute "method" for every link that could have values "get", > "post", "delete" etc. That way I could, for example, add tree links, > that look like normal links, after a discussion forum message. Those > could have labels such as "Show parent", "Reply" and "Remove". The > user agent would be aware that the first link just displays data (and > could be prefetched), second modifies data and the last one destroys > data. UA could even default to different cursors or whatever to > differentiate between different types. In addition to this, we could > have "get-with-form-data", "post-with-form-data" (as usual) and > "delete-with-form-data" and the UA would send all successful form > controls upon link activation which would save repeating some session > book-keeping data in every link (usually every link must have at least > some session data; more about this later). +1 Incidentally, what's the way you 'almost "solve"' it with CSS? > 3) As per HTTP protocol, a compliant UA should NOT send any data to > server when user activates history action. So, I have to keep all > session related data on the form so that UA can keep track which data > belongs to which dialog. If my application stored any live session > data (instead of just user settings and other more or less static > things) on server end a single press of the back button would cause > the server and client to go out of sync and the whole logic would > collapse. Currently all links are problem because if I have 30 links > on a generated page, I have to repeat session data 30 times (once for > each link so that no data is lost once a link is activated). I cannot > use cookies because I want to support running multiple user accounts > in multiple UA instances (user1 in window1 and user2 in window2). > Cookies cannot fork either, see below. > > 4) and 5) The issue here is really a forking problem. Although I completely agree with you about the problem (and that cookies are not a solution), you already point out the obvious thing to do: > [1] As I think it further, I think _document_id_ is worthless because > even the server could generate an unique identifier for every page > (like getCurrentTime() for example). In my web applications, I actually go much further: not only does the server generate a unique id for each page view, it also generates a unique id for each link, form, and input element. This makes a whole bunch of headaches related to form processing simply go away. Avi
Received on Wednesday, 16 June 2004 11:42:55 UTC