On Thursday, July 7, 2011 5:46:44 PM UTC+2, Eugen Paraschiv wrote:
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
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
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
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
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
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
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
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
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.
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.
--
You
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
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
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.nehlme...@gmail.com wrote:
--
You received this message because you are
@Prefix(TOKEN_NAME)
public static class Tokenizer implements
PlaceTokenizerPayRequestListPlace {
// Since the place is injectable, we'll let Gin do the construction.
private final ProviderPayRequestListPlace placeProvider;
@Inject
public
14 matches
Mail list logo
