RE: Ajax Back/Forward History problem - saving document state by document.save()

Vladimir,

I don't think Karl is talking about saving state, so much as providing to a
page that can be in many states, enough information that it can recreate a
previous state.


RECAP OF THE PROBLEM
The slideshow example is a good one. The easiest way to do this is to have
20 slides stored on a server at 20 different URLs, and each slide can have
links to the next and previous ones. We would then just provide a link to
the slideshow itself, and users could come and interact with it. We could
also send links to people to go look at slide number 5.

But this slideshow sitting on our server is pretty cumbersome, and with all
the computing power we have on our desktops we could do a lot better. What
we want is a slideshow *application* that goes off and gets the slides (even
mixing in slides from other presentations, if we want). It's a lot more
efficient, but of course, as we know, the client-side slideshow application
now needs to know how to find slide 5 directly, if someone were to pass a
link to it.

Karl is saying that solutions have been proposed for letting the slideshow
application go straight to slide 5 (using the fragment identifier), but what
hasn't been worked out is how to get that information into the navigation
history.


POSSIBLE SOLUTION
I think Karl is right that some simple method is appropriate here, although
I think this could easily be an extension to the 'history' object, on
'window' (or whatever object is eventually defined to play the role that
'window' plays now), rather than a new method on 'document'. After all, it
is the container that is doing the navigating, not the document itself.

The next question becomes, what exactly do you save? I can't say I'm keen on
putting state information into the history list, in the way that the WHATWG
push and pop stuff does. (I'm assuming we wouldn't really want to save slide
number 5, for example?) Instead, I would like to see some kind of
standardisation on a client-side variable syntax. It's something I began to
think about quite a while ago in the context of XHTML 2, as a generic
solution to the specific problems posed by XFrames. URLs would be something
like this:

  http://www.example.org/mydoc.html#vars(a=data.xml,customerid=72)

Using this XPointer syntax we can clearly demarcate what is for the client,
and in the document we could access these values using something like the
XSLT variable syntax. Once we have the variables it would then be easy
enough to recreate the 'state' that is important--a lot better than actually
saving the full state. (For example, any documents that were retrieved when
loading the original state should have themselves been cached, so using
these parameters to recreate the state should not necessarily require going
back to the server.)

By the way, another use for this is in client-side applications that use
XHTML/XForms/SVG, etc., as their 'application language'. Our Sidewinder
Viewer does just this, allowing you to create more traditional, standalone,
desktop applications, with things like docking to the side of the screen and
autohiding, but with those features being driven by the XHTML document.
Since such 'application viewers' can be run from the command line just like
any other application, the target for any run-time parameters needs to be
the XHTML application being executed, rather than the 'application viewer'
itself. Of course we could put them on the command line:

  swviewer.exe -pos top -autohide true http://example.org/someapp.html

But far better to come up with a technique that is based on the URL, since
it will then mean that a web application can be invoked from a web page. The
client-side parameters could perhaps be available to script via an
args/argc/argv type arrangement, possibly on 'document'.

(Note that in our architecture, a 'web browser' is just another web
application to be loaded by the 'application viewer', so it could be invoked
like this:

  swviewer.exe browser.html#vars(url=http://www.example.org/mydoc.html)

The 'browser' web application then loads the URL specified. See
http://www.flickr.com/photos/mark-birbeck/61853700/ for screenshots of parts
of the 'browser' implemented with XForms.)

The final part of the jigsaw that I would suggest is needed, is some
standard 'back' and 'forward' events. A web application could then register
for the events, do something clever, and cancel the default behaviour if it
wished. (This would also allow applications to do something sensible with
'forward', if it wanted to.)

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

> -----Original Message-----
> From: public-webapi-request@w3.org 
> [mailto:public-webapi-request@w3.org] On Behalf Of Vladimir Kelman
> Sent: 08 January 2006 01:41
> To: public-webapi@w3.org
> Subject: Re: Ajax Back/Forward History problem - saving 
> document state by document.save()
> 
> 
> Karl Pongratz wrote:
> > 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.
> 
> Karl, I strongly believe that modifying browser's engines to save
> *state* in addition to URL just cannot be simple enough. I 
> highly doubt it would be implemented any soon.
> 
> As <isolani/> says here
> http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonTh
> atAjaxBroke,
>   "Part of the AJAX problem is understanding whether an AJAX 
> enhanced page is actually a web application, or is it still 
> just a web document?"
> 
> I believe that an AJAX enhanced page should be considered a 
> web application by itself. I also believe, that the best and 
> really easy solution would be to conditionally disable "Back" 
> and "Forward" buttons on an AJAX page. When I said 
> "conditionally" I meant that in case a user clicks one of 
> these buttons a browser should display a confirmation window 
> asking if user really wants to *leave application*.
> 
> Yes, it would break a "pure HTML ideology", but this ideology 
> applies to 
>    web pages, not to web applications.
> 
> AJAX web pages aren't first pages which would benefit from 
> conditionally disabling "Back" and "Forward" buttons. The 
> same issue arises for any web pages with dynamically modified 
> content: for pages with frames, for pages with Java applets 
> or ActiveX controls.
> 
> Even plain HTML pages generated by server-side (PHP, ASP, 
> etc.) script often experience troubles with "Back" and 
> "Forward" buttons. Consider a standard situation when a page 
> uses HTML form to POST to itself, or when server-side script 
> uses SESSIONS to save data on a server side. It immediately 
> breaks a normal behavior of "Back" and "Forward" buttons, 
> because document's *state* is not exclusively determined by a 
> URL, it may depend on a session variable or even data, 
> retrieved from a database.
> 
> So, again, such pages are web applications by themselves - 
> something similar to a graphical Windows desktop application, 
> and they should be able to restrict "Back" and "Forward" 
> buttons' behavior.
> 
> Internet Explorer does provide a way to do it with 
> onbeforeunload Event 
> http://msdn.microsoft.com/workshop/author/dhtml/reference/even
> ts/onbeforeunload.asp.
> Unfortunately, other browser's vendors consider themselves 
> more "purist" 
> and do not provide such ability. If you try to Google like 
> http://www.google.com/search?hl=en&lr=&rls=GGGL%2CGGGL%3A2005-
> 09%2CGGGL%3Aen&q=disable+back+button&btnG=Search
> you'll get a long list of messages from people struggling to 
> disable those buttons... I understand that controlling "Back" 
> and "Forward" 
> buttons' behavior from a loaded HTML document may introduce 
> some security risks, but I think that it well worth to 
> implement as standard behavior - advantages are immense.
> 
> --
> Vladimir Kelman
> http://www.vkelman.com
> Vlad@vkelman.com
> 
> 
>

Received on Sunday, 8 January 2006 13:40:46 UTC