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

[Ian Hickson]

On Wed, 16 Jun 2004, Mikko Rantalainen wrote:
> 
> 1) Allow controls that look like links and still use POST
> 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).

You can now do this in an indirect way in Web Forms + Web Apps by making a 
link be equivalent to a command, but I agree that's not the same.

(Like this:

  <input type="submit" action="foo.cgi" method="post" id="submitter"/>
  <a command="submitter"/>

...although of course that way you get a button _and_ a link.)

The main problem is that your suggestion:

   <a href="delete.cgi" method="post">Delete</a>

...is treated by current UAs as this:

   <a href="delete.cgi" method="get">Delete</a>

...and spidered at will. Maybe that's ok though.


> 2) Submit button localization
> 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.

Use the <button> element. It has separate label and value control.


> 3) The Back button
> 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.

Yeah, a per-window, per-site local filestore is on the plans for Web Apps, 
and I think would resolve this for you.


> 4) Duplicate window
> 5) Open link in new window
> 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.

Another solution is to not use multiple pages -- with Web Forms 2, when 
the user hits submit, instead of loading the remote page you can simply 
take the results and use them in your script.


> 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]

This sounds like a workaround more than a solution, although it could 
indeed work.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'