On 13 sep, 19:17, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > The rationale for dispatching a history change with a different token to the > current one? Probably more than one, but in my case: I want to fire the > history listeners without leaving a history token. In JS you can do this by > overwriting the existing token with 'replace'. In GWT's History, you used to > be able to do this in an undeprecated way by simply not writing the history > token out in the first place. > > Imagine you have a two-level menu. Clicking on an item in the top level > might give you a page, but it also might give you a sub-menu. You have no > way of knowing. You want the final page to write the history token, but you > want the menu item to fire the history listeners so your application can > respond.
I don't get it, sorry. > The problem with History is that it isn't just history. It should just fire > history listeners when the history actually changes and nothing more. There > should be a separate object for dealing with application state change. > Either that, or history should be renamed and go the whole hog. At the > moment, it isn't one or the other. There cannot be change events if there's nothing to change, so History needs a newItem() method (and back(), forward() and go()). Apart from that, it's just what you described: it "fires history listeners when the history actually changes". > But given that History isn't currently just about history, why remove the > ability to fire the listeners without writing a token while at the same time > adding the ability to write a history token without firing the listeners? There are basically two kinds of applications: those that write new tokens and then react to the change, and those that use another mechanism and write the new token afterwards. For the latter apps, they still need to be able to react to changes made by the user (going back and forth using the browser's buttons, or opening a bookmark) so they need to react to history changes too. Before this newItem(String,boolean), those apps had to remember the token they wanted to go to (passed to newItem) and ignore history change events for that token (events fired by their own call to newItem). The new API makes things simpler. > *And* be able to refire the listeners with the same old token but not fire > them with a different one except via writing a new token? Think of fireCurrentHistoryState as a kind of "refresh", just like there are History.back() and History.forward(). > FYI the thread you quote first says "and adds new functionality to address > the use cases that were raised after its removal:" which isn't correct > because it doesn't answer the one I raised. > > The second link you give was where I raised the issue, and has no reply to > my last posting, which is why I started this one. And having read it again within the context you explained above, I still don't understand your use-case. But what's clear is that if you want application state disconnected from "history state" (addressability/bookmarkability and back/forward navigation within your app), then yes you should roll your own listeners and event dispatcher and define how they interact with the "history stage". --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
