[whatwg] Web application issues (localization, session handling)
avi at beta4.com
Wed Jun 16 11:42:55 PDT 2004
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).
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
> 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
>  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.
More information about the whatwg