Neal Holtz writes:
> Is anyone else interested in having the server have some control over
> a clients history list?
> ... In these cases, you probably do not want to see these nodes put
> on the history list.
Dave Raggett replied:
I have been worrying about this too. ...
Another common case occurs with fill-out forms. Keeping a history of
the successive stages of filling out a form, and the updates to that
form by the server is of dubious value (it would only make sense in the
context of a multi-level UNDO mechanism). So it makes sense to flag
intermediate steps as not to be placed on the history stack. This could
be done by an element in the document's head or an HTTP header (the two
are formally equivalent).
So how about:
a) adding an attribute to the <A> element to rollback the
history stack to the node before the *last* occurrence of
the linked node, e.g.
<A HREF="main_doc.html" ROLLBACK>Return to Home page</A>
b) Defining a new HTTP header for history hints which servers
can generate based on META elements in document heads, e.g.
<META NAME="History" VALUE="discard">
For (b) clients would get the HTTP header
History: discard
Other values such as "rollback" may be useful. This seems preferable
to adding yet another element to HTML+. Let me know what you think,
and I will ammend the HTML+ spec.
Dave Raggett
----- End Included Message -----
>> Letovsky replies:
In http://procrustes.biology.yale.edu/genera.html#Extensions
(Subsection on Immediate Commands) I propose another approach to this
issue, based on techniques common in database interface tools.
Specifically, I propose:
o a hash table allowing arbitrary attribute+value pairs to
be associated with widgets (and documents).
o html extensions allowing those attributes to be accessed and set.
These include a header directive analogous -- I think -- to Dave's proposed
<META NAME="History" VALUE="discard">
which I called
<NOPUSH>
the idea being that inhibits pushing a new document onto the stack,
which is the standard client action.
The GET and PUT directives proposed there constitute an approach to
implementing a means of communicating fill-out form deltas in a
non-pushing context. I urge people thinking about this issue to look
beyond simply setting the visible values of the fields, and to consider
the need to manipulate invisible associated values. These may be previous
values of the fields, needed in order to create, e.g. SQL statements along
the lines of
update table set field = newvalue where field = oldvalue
as well as for undo change commands; also to store surrogate keys (ID#s)
which you may not want visible, but which the form needs to know about
in order to send the server a message that allows SQL to be generated that
refers to those keys.
Cheers.
-Stan