On Friday, May 13, 2011 5:02:49 PM UTC+2, Jens wrote:
>
> I also have a Places / Token question and as this thread topic is a more
> general I post it here.
>
> First of all I do not like the default PrefixAndToken implementation and I
> would like to have place history tokens like the ones here in the new google
> groups app (#!place-name/group-name/thread-id). Is this possible with the
> default implementation of PlaceHistoryMapper or do I have to write my own
> one? As I can only have one Tokenizer with an empty Prefix I could also have
> only one "AppPlace" tied to that Tokenizer and so the getToken() /
> getPlace() methods of that Tokenizer would have to do all the magic to make
> thinks work. I think this would also mean that this one "AppPlace" needs to
> hold/know all other places so that they can store their state. Seems to me
> that this is not the nicest approach. Has someone already tried it?
>
You don't need to have "this one 'AppPlace'", you can simply "bind" your
empty-prefix PlaceTokenizer with the "Place" type to use it as a catch-all
(and it could parse tokens into as many distinct Place subtypes as you
need).
If you only have that one PlaceTokenizer, then it won't be that different
from having your own PlaceHistoryMapper though, it just let your easily plug
a new PlaceTokenizer later on with slightly less refactoring.
@Prefix("")
class CatchAll implements PlaceTokenizer<Place> {
public Place getPlace(String token) {
if ("contactus".equals(token)) {
return new ContactUsPlace();
}
if (token.startsWith("foo/")) {
// parse what follows "foo/" and return a FooPlace
}
...
}
public String getToken(Place p) {
if (p instanceof ContactUsPlace) {
return "contactus";
}
if (p instanceof FooPlace) {
return "foo/" + getFooToken((FooPlace) p);
}
...
}
}
> How does Google do that here in Google Groups?
>
I suppose they use A&P, and it so, I suppose they use their own
PlaceHistoryMapper.
> What I currently try is to implement a custom PlaceHistoryMapper that
> allows me to support Places that extend from other places to reuse their
> state. Imagine you have a CustomerPlace that stores the currently selected
> customer id. That CustomerPlace would also have an activity because you can
> switch between customers and for each switch some stuff has to be done, e.g.
> load picture, check privileges of the user to present tasks that the user is
> allowed to do for that customer. Lets say once the task list is loaded you
> are able to edit the customer so there would be a EditCustomerPlace. Now the
> EditCustomerPlace also have to store that customer id because if you jump to
> that place directly via its history token you need that information. How do
> you handle these situations without code things twice?
>
You can have EditCustomerPlace extends CustomerPlace. If the "sub-token" in
both cases is the customer ID, then you can use the same PlaceTokenizer with
two distinct @Prefix (either have 2 classes, one simply extending the other
without doing anything else, apart from having its own @Prefix; or if you
use a PlaceHistoryMapperWithFactory, simply have 2 methods parameterized
with the 2 classes and distinct @Prefix:
@Prefix("customer") PlaceTokenizer<CustomerPlace> customer() { return new
CustomerPlaceTokenizer(); }
@Prefix("customer-edit") PlaceTokenizer<EditCustomerPlace> editCustomer()
{ return new CustomerPlaceTokenizer(); }
)
...or you could instead have a single PlaceTokenizer that knows about both
classes (and can thus be bound once to a single @prefix):
@Prefix("customer")
class CustomerPlaceTokenizer implemens PlaceTokenizer<CustomerPlace> {
public String getToken(CustomerPlace p) {
return ((p instanceof EditCustomerPlace) ? "edit" : "view") + ":"
+ p.getId();
}
...
}
So my Idea is to be able to do something like EditCustomerPlace extends
> CustomerPlace and to generate the EditCustomerPlace history token by reusing
> the one from CustomerPlace.
>
> Example:
>
> CustomerPlace -> #/customer/1
> EditCustomerPlace -> #/editcustomer/<CustomerPlace state>/<additional
> EditCustomerPlace state> -> #/editcustomer/customer/1/address
>
> I couldn't do that without a custom PlaceHistoryMapper, right? Or are there
> other/easier ways to reuse place states?
>
You're in control of the parsing for everything after the prefix, so it's up
to you to make it reusable across PlaceTokenizers.
--
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.
