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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment