On 13 sep, 23:29, "Ian Bambury" <[EMAIL PROTECTED]> wrote:
> 2008/9/13 Thomas Broyer [EMAIL PROTECTED]
>
> > 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".
>
> It fires history events when the history changes, it also fires history
> listeners when the history *hasn't* changed
"refresh" case
> and it fails to fire history listeners when the history *does* change.
when explicitly told and only when explicitly creating a new history
entry (newItem), to avoid workarounds where you keep track of the
token you're setting to ignore the subsequent history change event.
> What I'm trying to get an answer to is why it *used* to be OK to fire
> history listeners with a token but without affecting the history stack, but
> now, suddenly, it isn't.
It didn't: onHistoryChanged was public by mistake, and wasn't ever
documented. You used it because you knew what it did (with such a
name, it could have been an "internal but mistakenly public" method
called by internal code to setup internal state; it could have been
called by the same code that call HistoryListeners, rather than being
the code that call HistoryListeners), just like you could have used
JSNI to call it if had been private in the first place.
> It doesn't matter if you can't envisage a use for it, it's not been
> superceeded, so what is so evil about it? Why was it thought necessary to a)
> remove it completely and then b) reinstate it but deprecated?
See above and in the already linked threads: they thought they could
just have switched it to private, because that's what it should hae
been in the first place; but given that people were using it, they
deprecated it and added new methods to cover the main use cases
(including the one you listed yourself in your "bug report": "so the
last thing I do when creating the
site is History.onHistoryChanged(History.getToken());" and "What I
want (what I had) is a way to fire the listeners with the current
history token."). Your other use case ("Being able to call them with a
different token but not have a history item written was useful, too")
but apparently you weren't compelling enough ("(i.e. I can put the app
in a state which I don't want in the history stack) but that is not
strictly history, is it?"). I wouldn't say then that it "used to be
_OK_" (emphasis mine) to use it that way.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
