I am developing an application that uses an iFrame to display help
page content, while keeping the main page (which contains my GWT
widgets) unchanged.  This is being done to preserve the state of the
GWT widgets while various help pages are viewed by the user.

The fundamental problem is this:  A browser, if left to its own
devices (i.e., no GWT history hooks) will keep track of iFrame content
in its own history list.  In other words, if you have a plain HTML
page with an iFrame in it and some links in the containing page that
load stuff into that iFrame, the browser will keep track of what got
loaded and if you hit the back button the iFrame pages will be
reloaded in reverse order.  But unfortunately, setting up an
onValueChange() handler using History.onValueChangeHandler() in GWT
and managing the History list in the GWT manner will not prevent the
browser from adding its own items to its own internal history, and
those items will get interleaved with whatever items your write
yourself using History.newItem().

Furthermore, when a browser re-loads this content into the iFrame in
response to pushes of the Back button, then even if you have set up an
onValueChange() handler using History.onValueChangeHandler(), that
handler will not be informed (except for IE and hosted mode) of the
back button presses that result in restoring those pages that the
browser has stuck into its history list itself.  Nor will that handler
be informed when the URL loaded in the iFrame changes and the browser
detects this and adds items representing those changes to its own
history list.

The GWT History mechanism is clearly intended to keep track of state
changes that are generated within the GWT code that result in distinct
displayed states but which are not accompanied by changes to the base
URL.  It pretty much does that.  But when changes must occur to an
embedded iFrame in the course of using the application, the items
added to browser history by the browser get all tangled up with the
items that you add yourself via GWT's History (which of course works
by manipulating its own embedded, invisible iFrame).

For SEO and other reasons, I want my links that load help pages into
the iFrame to be regular anchors rather than Hyperlinks.  But I don't
think that Hyperlinks would resolve this issue, since the main problem
is that the browser is still doing its own thing with its history each
time the content document of an embedded iFrame is changed.  The
HyperLink widget is intended to signal a GWT application that it
should change its own internal state, not to signal a GWT application
that it should load something into an iFrame.

What I would really like is a feature that allows me to receive an
event when the browser adds an item of its own to the event list, and
also a way to update the hash on the URL that will not affect the
browser's internal history.  I have tried the following native method:

        public native static void setHashInUrl(String newHash) /*-{
          $wnd.location.hash = newHash;
        }-*/;

and it does set the hash in the URL without reloading the page (along
with its GWT content), but unfortunately the browser back button
behavior (i.e., its internal history list) gets all crazy with extra
items and items that do nothing (lots of them) when I use the above
method.  The only browsers that do not seem to have this problem are
hosted mode and IE.

Anyway, I am at the point with this that I am going to punt and just
hook the onLoad() event for the frame to perform GWT actions (like
adjusting the scroll position or injecting content into the loaded
page) each time a new URL is loaded into the iFrame.  I am going to
give up on trying to get the hash of the URL in the browser's address
bar to reflect the page that is presently loaded, because changing the
hash in response ot an iFrame load, while it can be done, wreaks havoc
with the back button's behavior for every browser except IE and the
hosted mode browser.  With this (punting) approach, the browser
maintains its own history, including the loaded help pages, and all
that I lose are the hashes in the URL that would allow a user to get a
permalink to the page with the presently-loaded iFramed help content.
Which I will sorely miss, but there doesn't seem to be a good solution
for this yet in GWT...unless someone here knows otherwise.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to