Re: Ajax Back/Forward History problem – saving document state by document.save()

Hi Lachlan, Ian & anyone else,

Lachlan,
I do not want to change the location via window.location.href = "..." 
because it will reload the entire page, that is exactly what I want to 
avoid.

Hence I suggested document.save() which saves the altered document to 
the web browser cache and at the same time gives it a new URI without 
reloading anything. (The altered document is a web page where a 
javascript array has been loaded via xmlhttp and from which new content 
has been created via DOM scripting)

I repeat, the URI which is passed as an argument to document.save() 
serves the purpose to identify the document(resource), the same as 
traditional resources. In this case it would be possible to bookmark a 
page or click the web browser reload button and yet the user will get 
the right document. If the altered document would be saved to the web 
browser cache without changing the URI the web browser probably wont 
recognize the document nor would it be possible to bookmark the page, 
respectively the web browser would show the wrong document if the user 
clicks the web browser reload button.

Ian,
You suggest pushstate which I don't clearly understand yet, however, the 
following paragraph states:
"Typically, the history list will consist of only URIs. However, a page 
can add <http://whatwg.org/specs/web-apps/current-work/#pushstate> state 
objects between its entry in the session history and the next 
("forward") entry. These are then returned to the script 
<http://whatwg.org/specs/web-apps/current-work/#popstate> when the user 
(or script) goes back in the history, thus enabling authors to use the 
"navigation" metaphor even in one-page applications."

I am not sure about "returned to the script", I don't really wont any 
script to be executed when the user navigates through the web browser 
history. With document.save() I really just want that the altered 
document becomes a new document in the web browser history including the 
URI. And as I understand pushstate doesn't care about bookmarking or the 
web browser reload button.

I also want to note that I wanted to propose something simple that 
solves the emerging Ajax web application web browser history problem, 
something that is strongly tight to the xmlhttp request object and would 
be easy to implement by user agent vendors. Solve a big problem with 
little effort, though I am definitely not sure if document.save() would 
be easy to implement nor if it is actually the best solution. However, 
the WebForms and WebApplications draft specification goes far beyond 
that and will probably require a huge effort to be implemented compared 
to a single document.save() or similar function.

Also, having the possibility to save altered documents with a new URI 
may perfectly fit into the Architecture of the World Wide Web, 
http://www.w3.org/TR/webarch/#pr-uri-collision

Thanks,

Karl

Lachlan Hunt wrote:

> Karl Pongratz wrote:
>
>> Yes, I alter the page content! A table with 20 rows is different than 
>> a table with 100 rows, so I think the content is altered. Isn't it? 
>> The additional table rows are generated via DOM scripting.
>
>
> Yes, I know the page content is altered.  I never said it wasn't.
>
>> The reason that I change the URI is
>
>
> My point was that if you change the URI (e.g. by calling 
> window.location.href = "...";), then that will load a new document, 
> not just alter the current page.  If that is not what occurs, could 
> you please elaborate.
>
>> b.) IMPORTANT. If the user calls the document with the 100 rows 
>> through the web browser history and than clicks the web browser 
>> Reload button then the server needs to know that the requested 
>> resource is a table document with 100 rows. That's only possible if 
>> the URI has changed.
>
>
> The URI is one way to remember the state, another is with a session 
> cookie from which the server can lookup the user's current state.
>
>> So it is probably not #pushstate or is it?
>
>
> I don't know, you haven't expressed yourself clearly enough for me to 
> determine for sure whether it is or not, but I believe it is.
>

Received on Sunday, 20 November 2005 09:37:05 UTC