Is it possible to go to a new Place without inserting a new history item?

[Eugen Paraschiv]

I'm trying to do a place change but avoid introducing a new history item. My current code is:
placeController.goTo(new ABCPlace(null));
which does trigger a:
HistoryImpl.newItem
I have searched the various discussions about changes in place navigation and such but found no answer on how to do this.
Any help is appreciated.
Thanks.
Eugen.

[Jens]

I think if you do not put a ABCPlaceTokenizer into the @WithTokenizers annotation it could work. But why do you need this for just one place? A Place is something you can navigate to and if you do not want a history token for it then you probably do not want that place? 

-- J.

[Eugen Paraschiv]

Yes, I am aware that if I don't include the tokenizer in the mapping, it works fine. The problem with that is that it's an all or nothing solution, whereas I'm looking for a programatic way of choosing when the navigation should add a new history item and when it should not. It seems to be a very simple thing to do - a flag in the PlaceChangeEvent (support for this seems to exist in various other gwt projects - GWTP for instance).
I'll also try to give more detail on my use case:
I'm navigating to a new Place/Activity with the url looking like this: ....abc:null. This page has a list of items, which can be selected, and this selection changes the URL as well, adding the id at the end - abc:1, abc:2. This happens automatically and so what I'm getting is two events added to the history - first abc:null and then, automatically abc:1. That messes with the history completely - back now clearly won't work (will go to abc:null).
So, what I'd like to do is make the first navigation (to abc:null) not add it's event to history (because I know that selection will add a history entry anyways). If I could do that, then a single entry would end up in history and the world will be right again :).
Thanks for the help.
Eugen.

[Jens]

Ah ok so you do a redirect from abc:null to abc:1 and do not want the redirect to appear in the history.

You could try to implement a custom Historian by implementing the interface or extending DefaultHistorian (thats the class that interacts with the History class) and set it to your PlaceHistoryHandler. Your custom Historian implementation could then check for these special cases and just do not call History.newItem() if its ask to put abc:null to the history. 

Maybe you could also just treat abc:null as "select the first entry in the list or select nothing if list is empty". Imagine you have a list with items whose ids are 3,1,2. If you go to abc:null you would select 3 as its the first entry. If the user then selects 1 you would have abc:1. Now the user selects 3 again and the url would be abc:3. So you have two urls/tokens that would result in the same selection and the back button should work like expected. The only downside is that its probably not useful if you can add items to the list (what happens if you insert a new item at the first position? When hitting the back button you would select the wrong item once you reach abc:null again).

-- J.

[Eugen Paraschiv]

Thanks for taking the time to go into this. I will go with the custom historian and see how that pans out. The id of the first item is indeed variable.
Thanks again for the suggestions.

On Jul 7, 2011 6:23 PM, "Jens" <jens.ne...@gmail.com> wrote:

[Abduxkur Ablimit]

@Prefix(TOKEN_NAME)
    public static class Tokenizer implements PlaceTokenizer<PayRequestListPlace> {

        // Since the place is injectable, we'll let Gin do the construction.
        private final Provider<PayRequestListPlace> placeProvider;
        @Inject
        public Tokenizer(Provider<PayRequestListPlace> placeProvider) {
            this.placeProvider = placeProvider;
        }
       
        @Override
        public String getToken(PayRequestListPlace place) {

-----------------------------------------------------------
            return place.getPlaceName();   /* change this to  return "";  */

-----------------------------------------------------------------------
        }

        @Override
        public PayRequestListPlace getPlace(String token) {
            PayRequestListPlace place = placeProvider.get();
            place.setPlaceName(token);
            return place;
        }
    }

---

From: Jens <jens.ne...@gmail.com>
To: google-we...@googlegroups.com
Sent: Friday, July 8, 2011 12:22 AM
Subject: Aw: Re: Aw: Is it possible to go to a new Place without inserting a new history item?

--
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/-/Usf_oJa3GiUJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

How about fixing the root issue? namely that you're firing a second place change automatically just after the "abc:null". as I understand it, your "abc:null" place means "the list of items with the first one selected", which is different from "the item of id 1, with the list of items where it'd be selected" (that'd be the definition of "abc:1"). 

[Abduxkur Ablimit]

you said:"first abc:null and then, automatically abc:1. That messes with the history completely - back now clearly won't work (will go to abc:null). " this is because of ur ABCActivity is not singlton, if it is singlton it wont call the method(probably initial method) which will setPlaceName(null); OR this method is called in activity's start method, because when you request an activity it will call the start method,but in same activity's different place. 

---

From: Thomas Broyer <t.br...@gmail.com>
To: google-we...@googlegroups.com
Sent: Friday, July 8, 2011 4:46 PM
Subject: Re: Aw: Is it possible to go to a new Place without inserting a new history item?

--
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/-/bwG6qU0ZwTYJ.

[Eugen Paraschiv]

I get where you're coming from with this, but consider this scenario:
I now have the following entities in the list: 1, 2, 3, so the first element in the list would be 1. When going to the list, I would go to abc:1 which is fine - 1 will be selected and nothing else will happen (a place changed event will still be fired, but GWT will figure out that I'm navigating to the same place and ignore it). But then, 1 is deleted and so the list is 2, 3..., so the hardcoded navigation to 1 doesn't work any more. I cannot keep recalculating the URLs based on the first element of the list, because that would mean HTTP requests and queries just to navigate somewhere. What's worse is that 1 2 3 are id's so it will be dependent on the id generation strategy I'm using - if for instance 1 is deleted, then it may be reused for a new entity (it won't but just for the sake of the argument), which would lead to invalid bookmarks.
Perhaps the solution is to consider abc:null as a place where no element is selected and then let the user select the element.
Thanks for the feedback.
Eugen.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

[Eugen Paraschiv]

That is true. In my case however, making the activity a singleton introduces a degree of complexity into the system, and I would rather not deal with that complexity unless I have to. If your use case is such that you need the client-side caching and you have done proper profiling and reached this conclusion, good, but to use singletons for performance reasons (I'm guessing that's the idea behind the singleton activities) seems to be a premature optimization in my case.
Thanks for the answer and the help.
Eugen.

[Thomas Broyer]

On Friday, July 8, 2011 12:57:01 PM UTC+2, Eugen Paraschiv wrote:

I get where you're coming from with this, but consider this scenario:
I now have the following entities in the list: 1, 2, 3, so the first element in the list would be 1. When going to the list, I would go to abc:1 which is fine - 1 will be selected and nothing else will happen (a place changed event will still be fired, but GWT will figure out that I'm navigating to the same place and ignore it). But then, 1 is deleted and so the list is 2, 3..., so the hardcoded navigation to 1 doesn't work any more.

That's what you're doing right now, not what I'm suggesting.

 

I cannot keep recalculating the URLs based on the first element of the list, because that would mean HTTP requests and queries just to navigate somewhere.

Why would you "recalculate the URLs"? (see below)

When you go to "abc:null", it shows the list and 'selects' the first one (be it abc:1, or abc:2, it depends what the list contains)

When you go to "abc:1", it shows the first item (if it exists) and also shows the list with that item selected.

Where you might have issues is if your list and detail are two distinct activities, but then again, it's a design flaw: you're not navigating to "abc:1", you're navigating to "abc:null" (which happens to also display "abc:1"), firing a subsequent navigation to "abc:1" is IMO a mistake, and that's what you should try to fix, rather than workaround the consequences.

There are several possible fixes:

 - abc:null triggers a special details activity (or more probably a details activity in a special state) that waits for an event on the EventBus before doing anything. the list activity, when loading from "abc:null", dispatches such an event pointing to the first item in the list.

 - "calculating places", as you said, each time you want to go to "the list", to actually go to "the first item in the list" instead.

and there are probably others.

 

What's worse is that 1 2 3 are id's so it will be dependent on the id generation strategy I'm using - if for instance 1 is deleted, then it may be reused for a new entity (it won't but just for the sake of the argument), which would lead to invalid bookmarks.

That's another issue, dependent on your PlaceTokenizer and ID generation stategy. It's up to you to define whether a given "URL" can be reused or not.

 

Perhaps the solution is to consider abc:null as a place where no element is selected and then let the user select the element.

It'd make things much easier for sure!

but the event-based approach above shouldn't be that hard to implement I guess.

[Jens]

Am Freitag, 8. Juli 2011 12:57:01 UTC+2 schrieb Eugen Paraschiv:

Perhaps the solution is to consider abc:null as a place where no element is selected and then let the user select the element.

Thats what I do when a user visits a place the first time after a fresh app start. Once the user selects something I go to the new place that reflects the selection. In addition I update the menu item link that leads to that place. That way the user can navigate away..but when he comes back to that place he sees the last selection he has done. So basically I only do placeController.goTo(..) when the state changes inside a place. All other navigation is done directly with Hyperlink instances with the history token as url (so all my navigation widgets listen to PlaceChangeEvent and update the corresponding hyperlink).

For example I have a side menu which contains new Hyperlink("#employees"). Once an employee is selected in the list the side menu item url gets updated to "#/employees/<selected id>". Thus the selection is saved inside the hyperlink itself.

That was a nice solution for me and maybe for you too. Just imagine if you select an item automatically, it may occur the case that the user is not interested to see that automatically selected item and then you have also done some additional http requests just to load "the one the user is not interested in".

-- J.

[Jens]

And what about user experience? If the user actually bookmarks abc:null and the app treats abc:null as "select the first entry in the list" then the selection may change over time if some editing is done (adding/removing items). If the user is unexperienced and is not interested in the "url thing" it is maybe confusing that a bookmark gives different results over time.

That can not be solved by a nifty url history token because the interpretation of that token is the problem in that case. The only solution would be to not use something like abc:null and instead to figure out which item is the first in the list to be able to select it on an "id" basis prior the actual place change. Or am I missing something?

Because of the user experience with bookmarking we do not select anything like "the first entry in that list/dropdown whatever" by default in our app.

[Eugen Paraschiv]

Good point about the user experience - it does have a potentially high degree of inconsistency if I make abc:null select the first entry, same as abc:1 this time and abc:2 the next. I will do as you suggest, abc:null will select nothing, and it will be up to the user to actually select something from the list. Initially I tried not to do that so that I wouldn't have to implement an unselected state for some of the widgets, but I'm seeing now that the complexity added to navigation and state management simply isn't worth it.
Thanks again for the help and suggestions.
Eugen.

--
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/-/zGVFz_WFWKEJ.

[Eugen Paraschiv]

To answer some of your feedback - there is a single Activity for the entire page. About the calculation of the URL, the reason behind URL recalculation each time was to be able to navigate to abc:id directly and bypass the entire problem with first going to abc:null and handling that scenario. The solution I try out is making abc:null unselected - no item will be selected at that point.
Thanks for the feedback. I will keep the event based solution in mind for more complex scenarios.
Eugen.