On 14 mai, 13:22, Alyxandor <a.revolution.ultra.b...@gmail.com> wrote:
> @Thomas, AYE! Your example does work best, provided users don't Ctrl
> +Click to open in a new Window.
That's handled by the "if (impl.handleAsClick(Event.as
(event.getNativeEvent())))" line (in 1.6; in 1.5 you'd have to use
something similar to the HyperlinkOverride from the Incubator)
[...]
> ...And yes, I DO overcomplicate everything. Mainly because I'm oh-so-
> picky. This was what it took for me to get directional history
> support that would prevent two iframes from being opened, prevent
> "link-lock" when the iframe was closed without changing the token,
> detect which direction the user clicked, and differentiate between
> closing the iframe and opening a new one {which also closes the old
> window, but doesn't bother playing with the tokens.}
If you clearly defined the UI flow before hand, you probably wouldn't
have had to go such a convoluted path. Simple things work best.
> Simple answers are usually the best, but I had to do this because my
> client was picky and actually tested everything.
Did they test clicking twice very quickly on either prev or next page
browser buttons? History (except in IE) is handled using timers that
regularly check the URL and compare its "hash" part with the one
that's supposed to be the "current one"; in the History design, what
counts is the "final" token, not which tokens are navigated through
towards the "final" token (when clicking more than once on the prev/
next browser buttons I mean).
Using the kind of code I described at the ned of my last message would
make things much more reliable (and better represents you UI flow):
1. in onValueChange (history event), open your popup with the iframe
2. use Anchors instead of Hyperlinks (wrap them in a SimplePanel if
you need the wrapping div) and:
a) if History.getToken() is the same as the link's target token,
History.fireCurrentHistorystate()
b) else, call History.newItem
both would result in onValueChange being called and re-open the
popup
(eventually, in 2, I think you could just continue using Hyperlinks
and add a ClickHandler doing the a) thing; the default History.newItem
behavior would in this case not fire the handlers; I just find it
better to use an Anchor here --Hyperlink::addClickHandler will soon be
deprecated, so it seems I'm not the only one thinking this way--)
You could also, of course, call History.newItem in the method that
opens the popup/iframe (ensures that you're at the "correct" history
state), and have your Anchor's ClickHandler and History's
ValueChangeHandler call that method directly (the extra call to
newItem when the method is called from the History's
ValueChangeHandler would be a no-op, but you could eventually
"protect" it comparing History.getToken() with your target token).
I still think you shouldn't use History to open popups (particularly
if you don't change the history state when the popup is closed).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
