- From: Mikko Rantalainen <mira@cc.jyu.fi>
- Date: Wed, 16 Jun 2004 19:32:16 +0300
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...
Received on Wednesday, 16 June 2004 09:32:16 UTC