>
> Regarding History object and the firing of ValueChangeEvents... I've
> confirmed that the events are not being fired with this:
>
> History.addValueChangeHandler(new ValueChangeHandler<String>() {
>
> @Override
> public void onValueChange(ValueChangeEvent<String> event) {
> Window.alert("history changed");
> }
>
> });
>
>
A fresh GWT 2.4 app only containing the following code will always fire a
ValueChangeEvent whenever the history stack changes (not tested in IE):
@Override
public void onModuleLoad() {
History.addValueChangeHandler(new ValueChangeHandler<String>() {
@Override
public void onValueChange(final ValueChangeEvent<String> event) {
RootPanel.get().add(new Label("History changed: " +
event.getValue()));
}
});
History.fireCurrentHistoryState();
}
So I am not quite sure how I could make it not work :) I guess it only
stops working if the browser does not fire the corresponding native event
but that would be a browser issue.
I am wondering if the use of Places and the MVP framework has something to
> do with this... The way navigation works in my app is via
> "clientFactory.getPlaceController().goTo(place);" and if the user stays
> within the same "Place" (ie same token prefix) no event is fired. However,
> I am able to detect the user navigation via:
>
> eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
> PlaceChangeRequestEvent.Handler() {
>
> @Override
> public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
> Window.alert("new place requested");
>
> }
>
> });
>
PlaceController doesn't do any magic. It knows the current place and does
an equals() check with the provided place you want to go to. If the current
place and the new place are equal() nothing will happen. If they are not
equal() a PlaceChangeRequestEvent will be fired and (unless the user denies
it by choosing cancel in the confirmation dialog that appears if any
activity returns a warning in Activity.mayStop()) a PlaceChangeEvent will
be fired just after it. So you generally should always see both events.
Take a look at the source code of PlaceController... its really easy to
understand whats going on.
As your problem is somehow dependent on your place token, have you already
checked your PlaceTokenizers if they work correctly? You could also
activate GWT logging to see some log statements from PlaceController
(http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideLogging.html#Super_Simple_Recipe_for_Adding_Logging)
-- J.
Am Mittwoch, 29. Februar 2012 18:59:30 UTC+1 schrieb Lars:
>
> Thanks for your input.
>
> Regarding History object and the firing of ValueChangeEvents... I've
> confirmed that the events are not being fired with this:
>
>
> History.addValueChangeHandler(new ValueChangeHandler<String>() {
>
> @Override
> public void onValueChange(ValueChangeEvent<String> event) {
> Window.alert("history changed");
> }
>
> });
>
> I am wondering if the use of Places and the MVP framework has something to
> do with this... The way navigation works in my app is via
> "clientFactory.getPlaceController().goTo(place);" and if the user stays
> within the same "Place" (ie same token prefix) no event is fired. However,
> I am able to detect the user navigation via:
>
> eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
> PlaceChangeRequestEvent.Handler() {
>
> @Override
> public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
> Window.alert("new place requested");
>
> }
>
> });
>
> And since what I'm really after is the user navigation not the tokens
> themselves, this is sufficient for me... Why I'm not getting the
> ValueChangeEvents from the History object is a mystery to me...
>
> On Monday, February 27, 2012 5:38:31 PM UTC-5, Jens wrote:
>>
>> I like the idea, but I'm finding that the value change event only fires
>>> when prefix portion of the token changes.
>>>
>>> Thanks for your reply... By the way, am I right that the value change
>>> event only fires this way?
>>>
>>
>> History.addValueChangeHandler() always fires a ValueChangeEvent if the
>> history stack changes. Otherwise it wouldn't be possible to switch between
>> places of the same type but with different internal state (e.g.
>> #DetailsPlace:1 and #DetailsPlace:2).
>>
>> Honestly I wouldn't skip any history tokens when a user hits the back
>> button. When the user edits 3 documents in a row then he maybe wants to
>> switch between them back and forth for some reason. I found it more natural
>> if I would have to hit 3 times the back button to be back at the INDEX
>> place if I have navigated to three different documents. Thats what you
>> would expect from normal web navigation.
>> In addition your app can provide a link like "back to index view" so that
>> the user can directly jump back to the INDEX place if I really wants to.
>>
>> -- J.
>>
>
Am Mittwoch, 29. Februar 2012 18:59:30 UTC+1 schrieb Lars:
>
> Thanks for your input.
>
> Regarding History object and the firing of ValueChangeEvents... I've
> confirmed that the events are not being fired with this:
>
>
> History.addValueChangeHandler(new ValueChangeHandler<String>() {
>
> @Override
> public void onValueChange(ValueChangeEvent<String> event) {
> Window.alert("history changed");
> }
>
> });
>
> I am wondering if the use of Places and the MVP framework has something to
> do with this... The way navigation works in my app is via
> "clientFactory.getPlaceController().goTo(place);" and if the user stays
> within the same "Place" (ie same token prefix) no event is fired. However,
> I am able to detect the user navigation via:
>
> eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
> PlaceChangeRequestEvent.Handler() {
>
> @Override
> public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
> Window.alert("new place requested");
>
> }
>
> });
>
> And since what I'm really after is the user navigation not the tokens
> themselves, this is sufficient for me... Why I'm not getting the
> ValueChangeEvents from the History object is a mystery to me...
>
> On Monday, February 27, 2012 5:38:31 PM UTC-5, Jens wrote:
>>
>> I like the idea, but I'm finding that the value change event only fires
>>> when prefix portion of the token changes.
>>>
>>> Thanks for your reply... By the way, am I right that the value change
>>> event only fires this way?
>>>
>>
>> History.addValueChangeHandler() always fires a ValueChangeEvent if the
>> history stack changes. Otherwise it wouldn't be possible to switch between
>> places of the same type but with different internal state (e.g.
>> #DetailsPlace:1 and #DetailsPlace:2).
>>
>> Honestly I wouldn't skip any history tokens when a user hits the back
>> button. When the user edits 3 documents in a row then he maybe wants to
>> switch between them back and forth for some reason. I found it more natural
>> if I would have to hit 3 times the back button to be back at the INDEX
>> place if I have navigated to three different documents. Thats what you
>> would expect from normal web navigation.
>> In addition your app can provide a link like "back to index view" so that
>> the user can directly jump back to the INDEX place if I really wants to.
>>
>> -- J.
>>
>
Am Mittwoch, 29. Februar 2012 18:59:30 UTC+1 schrieb Lars:
>
> Thanks for your input.
>
> Regarding History object and the firing of ValueChangeEvents... I've
> confirmed that the events are not being fired with this:
>
>
> History.addValueChangeHandler(new ValueChangeHandler<String>() {
>
> @Override
> public void onValueChange(ValueChangeEvent<String> event) {
> Window.alert("history changed");
> }
>
> });
>
> I am wondering if the use of Places and the MVP framework has something to
> do with this... The way navigation works in my app is via
> "clientFactory.getPlaceController().goTo(place);" and if the user stays
> within the same "Place" (ie same token prefix) no event is fired. However,
> I am able to detect the user navigation via:
>
> eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
> PlaceChangeRequestEvent.Handler() {
>
> @Override
> public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
> Window.alert("new place requested");
>
> }
>
> });
>
> And since what I'm really after is the user navigation not the tokens
> themselves, this is sufficient for me... Why I'm not getting the
> ValueChangeEvents from the History object is a mystery to me...
>
> On Monday, February 27, 2012 5:38:31 PM UTC-5, Jens wrote:
>>
>> I like the idea, but I'm finding that the value change event only fires
>>> when prefix portion of the token changes.
>>>
>>> Thanks for your reply... By the way, am I right that the value change
>>> event only fires this way?
>>>
>>
>> History.addValueChangeHandler() always fires a ValueChangeEvent if the
>> history stack changes. Otherwise it wouldn't be possible to switch between
>> places of the same type but with different internal state (e.g.
>> #DetailsPlace:1 and #DetailsPlace:2).
>>
>> Honestly I wouldn't skip any history tokens when a user hits the back
>> button. When the user edits 3 documents in a row then he maybe wants to
>> switch between them back and forth for some reason. I found it more natural
>> if I would have to hit 3 times the back button to be back at the INDEX
>> place if I have navigated to three different documents. Thats what you
>> would expect from normal web navigation.
>> In addition your app can provide a link like "back to index view" so that
>> the user can directly jump back to the INDEX place if I really wants to.
>>
>> -- J.
>>
>
Am Mittwoch, 29. Februar 2012 18:59:30 UTC+1 schrieb Lars:
>
> Thanks for your input.
>
> Regarding History object and the firing of ValueChangeEvents... I've
> confirmed that the events are not being fired with this:
>
>
> History.addValueChangeHandler(new ValueChangeHandler<String>() {
>
> @Override
> public void onValueChange(ValueChangeEvent<String> event) {
> Window.alert("history changed");
> }
>
> });
>
> I am wondering if the use of Places and the MVP framework has something to
> do with this... The way navigation works in my app is via
> "clientFactory.getPlaceController().goTo(place);" and if the user stays
> within the same "Place" (ie same token prefix) no event is fired. However,
> I am able to detect the user navigation via:
>
> eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
> PlaceChangeRequestEvent.Handler() {
>
> @Override
> public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
> Window.alert("new place requested");
>
> }
>
> });
>
> And since what I'm really after is the user navigation not the tokens
> themselves, this is sufficient for me... Why I'm not getting the
> ValueChangeEvents from the History object is a mystery to me...
>
> On Monday, February 27, 2012 5:38:31 PM UTC-5, Jens wrote:
>>
>> I like the idea, but I'm finding that the value change event only fires
>>> when prefix portion of the token changes.
>>>
>>> Thanks for your reply... By the way, am I right that the value change
>>> event only fires this way?
>>>
>>
>> History.addValueChangeHandler() always fires a ValueChangeEvent if the
>> history stack changes. Otherwise it wouldn't be possible to switch between
>> places of the same type but with different internal state (e.g.
>> #DetailsPlace:1 and #DetailsPlace:2).
>>
>> Honestly I wouldn't skip any history tokens when a user hits the back
>> button. When the user edits 3 documents in a row then he maybe wants to
>> switch between them back and forth for some reason. I found it more natural
>> if I would have to hit 3 times the back button to be back at the INDEX
>> place if I have navigated to three different documents. Thats what you
>> would expect from normal web navigation.
>> In addition your app can provide a link like "back to index view" so that
>> the user can directly jump back to the INDEX place if I really wants to.
>>
>> -- J.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/BYGyVO8XeWwJ.
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.
