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

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.

The reason that I change the URI is
a.) That the web browser knows that the document with the 100 rows is a 
different document than the one with the 20 rows.
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 table is a very simple example. The URI could change from 
document/apples to document/bananas or whatever, so I think is important 
that when I alter a document via DOM scripting that it is actually a new 
resource in the web browser history and URI. because it is actually a 
new document/resource.

So it is probably not #pushstate or is it? I am also not certain if the 
WHATWG topics are a bit of an overhead and I wonder when they will be a 
reality in all major web browsers.

Karl

Lachlan Hunt wrote:

> Karl Pongratz wrote:
>
>> One major thing that keeps me from using Ajax up to the limits is the 
>> web browser Back/Forward history problem; it looks like that many 
>> users just can't live without it. I am now wondering if this problem 
>> wouldn't be best solved by adding a new document method, something 
>> like document.save(pathname), which would save the active document 
>> state to the web browser cache (user agent cache).
>
>
> See the WHATWG's work in this area.
> http://www.whatwg.org/specs/web-apps/current-work/#pushstate
>
>> The pathname argument would specify the changed portion of the URL, 
>> including any search string.
>
>
> If the URI has changed, why would you need script to add it to the 
> history when that happens already?  It seems to me that this feature 
> is only useful for cases where script alters the page content but not 
> the URI.
>

Received on Saturday, 19 November 2005 19:11:46 UTC