[whatwg] Web application issues (localization, session handling)

[Mikko Rantalainen]

There has been a lot of discussion about different controls web 
applications need but I would want to raise discussion on a few 
other issues with developing web applications.

First of all, I'll declare that I consider a "web application" to be 
an application that has front end or user interface as much similar 
to a static web page as possible. This is because the user is 
(hopefully) already familiar how to navigate static web pages so why 
not build on that knowledge?

As I've tried to build such applications (and without JavaScript so 
the application would be accessible with older and special utility 
user agents such as mobile devices and braille displays, hopefully 
with aural user agents too), I've hit a couple of hard problems. All 
of these deal more or less with session handling.

1) Allow controls that look like links and still use POST
2) Submit button localization
3) The Back button
4) Duplicate window
5) Open link in new window

Detailed description of every issue follows:

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).

2) I don't know who was the genius behind the decision to use 
"value" attribute as the label of the button but that decision 
forces me to do actions according to control names. If I have 
buttons "add" and "rm" and those are localized in Finnish as "Lisää" 
and "Poista", I don't have any other way to decide which one was 
pressed but check if form control "add" was set. (I cannot easily 
check for "Lisää" and "Poista", because environment language could 
have been changed by another user / via another window while this 
dialog was open.) This causes needless extra book-keeping to make 
sure that I never use name "add" for any other element, like for 
example for a text input because it would be always successful! How 
about "label" attribute so that "value" can be what it was supposed 
to be? As a workaround I can name all such controls as 
"action_something" and look through controls that match regexp 
"action_.*" only... Namespace collisions of different controls get 
harder to avoid when I need to keep very much of session data in 
addition to user input and the whole page is generated on the fly.

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. Say, we have a 
dialog A, which has possible actions 01, 02 and 03. 01 leads to 
dialog B, 02 leads to dialog C and 03 leads to dialog D. User first 
activates 02 with "Open in a new window" and server returns B. Then 
the user select action 03 on the dialog B that leads to dialog E. 
Then the user changes to previous window and select 03 which should 
lead to dialog D (because the other window had dialog A open). Throw 
a couple of Back-buttons in the mix and you begin to see the 
issue... Clearly the user wanted to use multiple windows and 
back-button presses to do the actions, so the issue isn't how to 
prevent opening new windows or disabling back-button. The issue is, 
how to still keep the session handling sane while using logically 
connectionless protocol such as HTTP? My current answer to this is 
to keep as much data about the session embedded in the page as 
possible. If the UA is able to duplicate windows or display 
historical pages, it will use the embedded data in that copy, too.


For the 3), 4) and 5) I'd propose adding two magical hidden field 
names: "_frame_id_" and "_document_id_". Both would be always 
successful and their values would be set automatically. The 
_frame_id_ would be unique for the current set of page instances (in 
practice, an unique identifier for all the windows and frames) and 
_document_id_ would be unique for all documents (pages) the UA 
handles, including past, current and future. _frame_id_ could be 
implemented as a serial number that has been attached to every 
window or frame and every time a new window or frame were created, 
the serial number would be increased by one. The _document_id_ would 
be similar, but it would be increased every time any document had 
been loaded in any frame. This would include going back and forward 
in the history. The server end could then use these two values to 
figure out which dialog sent out the event. [1]


Thanks for reading this far, hopefully you could decipher my 
ramblings. Any thoughts?

-- 
Mikko

[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). However, being able 
to differentiate between two similar calls that come from two 
identical windows could be beneficial in some cases. I left the idea 
floating still - perhaps somebody comes up with something better...