Brian, I appreciate your response and apologize for not having noticed it until now.
I've moved on from this issue for the moment and will probably revisit it once I get my initial deployment out the door. Your suggestion is reasonable but, as I mentioned, I have some doubts as to whether it would work, because it seems to me that changes to the non-GWT-History iframe can affect the browser's own history without informing the GWT History mechanism. However, until I actually try what you are suggesting, I can't be sure that it would not work; it may be that when the change to the contents of the non-GWT-History iframe are made from a Hyperlink rather than by a direct user click on an anchor that targets that iframe, the browser will not place its own disruptive items on the History list in addition to those entered by GWT. So I *will* try that more virtuous approach but, as St. Augustine said, "not now." Another concern, however, is that as someone fairly new to developing for the public net, I'm a bit paranoid about the shadowy area of SEO, and also AdSense spidering, and would like to keep things as vanilla as possible when it comes to links to other pages. Using an iframe alone is already a little "iffy" in that regard, because there is some question as to whether the links to the framed page will be credited back to the containing page. If I add on top of that dual paths for the bots vs. the humans, the possibility that this will be perceived as "cloaking" is added to the already cloudy mix. So, I'll try your suggestion but may still stay with the simpler (albeit non-ideal from the standpoint of bookmarking) approach, even if your suggestion works. Carl On Nov 2, 4:58 am, Brian <[email protected]> wrote: > I'm not sure that I follow completely, but perhaps a different > approach would be to serve up two versions of the help. One would be > under control of GWT and the other would be more static and would be > shown only to search engines. You could probably work out a way that > they would both show the same content so there wouldn't be versioning > issues. Again, I'm not sure I followed well enough to know if this > would help with your problem, but it's a different approach to think > about. > > -Brian > > On Oct 30, 5:19 am, Carl <[email protected]> wrote: > > > > > 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=.
