Re: Activities & Places, token question

[jamo . afsco]

All of these are good solutions.  I used the ideas from this post and came 
up with my own solution
>
> public class AppPlace extends Place {

// You can reference places without using the constructor  ie. 
AppPlace.UnitCostPlace
public static AppPlace UnitCostPlace = new AppPlace(Location.unitCost);
public static AppPlace Home = new AppPlace(Location.home);
 // The token names match the enum names
private static enum Location {
home,
unitCost;
}
 private Location location;
 private AppPlace(Location location) {
this.location = location;
}

@Prefix("")
public static class Tokenizer implements PlaceTokenizer {
 public AppPlace getPlace(String token) {
Location location = Location.valueOf(token);
 switch(location) {
case home:
return Home;
case unitCost:
return UnitCostPlace;
default:
return null;
}
}

public String getToken(AppPlace place) {
return place.location.name();
}
}
}

The nice thing about this solution is that you replace strings with enum 
constants so it is more type safe.  Also you don't have to construct 
Places, you just reference them.

Each time you need to add a new place, you just and a new enum constant and 
a public static AppPlace member variable.  

You also get the benefit of using the == operator in your ActivityMapper 
instead of *instanceof.*

public class AppActivityMapper implements ActivityMapper {

public Activity getActivity(Place place) {
if(*place == AppPlace.Home*) {
return new HomeActivity();
} else if(*place == AppPlace.UnitCostPlace*) {
return new UnitCostActivity();
} else 
return null;
}
}

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Activities & Places, token question

[SurfMan]

Sorry to wake up an old thread, but I stopped by after pulling my hair out 
about places with empty tokens.

I don't understand the reasoning behind a token being mandatory. If a place 
is named "Login" and it does not require any tokens, then why can't I just 
use myapp.html#Login without resorting to a random token, an empty token or 
some generic place that functions as a catchall.


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

Re: Activities & Places, token question

[Thomas Broyer]

[+Cc GWT Group]

On Fri, Nov 25, 2011 at 3:38 PM, SurfMan  wrote:
> Sorry to wake up an old thread, but after struggling with an empty
> place/token I ended up here too...
>
> I just don't understand why "#blah" would end up as the default place
> "" with token "blah", and why it's not place "blah" with an empty/null
> token. What is the reasoning behind this?

The serialization and deserialization processes have to be symmetric.
So if you allow an empty prefix and choose to serialize {prefix="",
token="foo"} as #foo (rather than #:foo), then you have to parse #foo
as {prefix="", token="foo"} (rather than {prefix="foo", token=""}).

The current choice is more flexible than the alternative, as it allows
the PlaceTokenizer for the empty prefix to create any kind of Place
depending on the token (if that's what you want), and falling back to
'null' for unknown tokens.
With the alternate design, the generated PlaceHistoryMapper would then
look for a PlaceTokenizer for the prefix "foo" and won't find any so
it'd fall back to the default place, always, without any hook for you
to customize this behavior).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Aw: Re: Aw: Re: Activities & Places, token question

[Jens]

Thanks Thomas that helps quite a bit. I have chosen the catch all tokenizer 
approach with some additional code to make parsing more reusable and it was 
easy to implement.

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

Re: Aw: Re: Activities & Places, token question

[Thomas Broyer]

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 {
  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 customer() { return new 
CustomerPlaceTokenizer(); }
   @Prefix("customer-edit") PlaceTokenizer 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 {
  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// 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Activities & Places, token question

[Alex]

Thank you so much for your reply, this has really helped me. The
solution for me was to implement my own PlaceHistoryMapper, now I'm
getting the exact behaviour I was looking for, while keeping within
the A&P framework.

Many thanks,
Alex

On May 13, 2:28 pm, Thomas Broyer  wrote:
> First, you could use the empty string instead of a "random token", and it
> would give you a /#ContactUsPlace: token.
>
> There's also the possibility to either put a bunch of "places" into a single
> Place class, and using the "token" to disambiguate them (e.g.
> /#CommonPlace:ContactUs); or you could instead use different Place classes
> but a single PlaceTokenizer (better IMO) with the same results.
> ...and because an empty @Prefix is simply ignored when generating the token,
> you could have /#contactus that way.
>
> Finally, but you shouldn't need it for your use case, you can provide your
> own implementation of PlaceHistoryMapper instead of relying on the generator
> (you'd lose all the magic related to @WithTokenizers and @Prefix though and
> have to do it all by yourself).

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Aw: Re: Activities & Places, token question

[Jens]

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? How does 
Google do that here in Google Groups?

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?

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// -> #/editcustomer/customer/1/address

I couldn't do that without a custom PlaceHistoryMapper, right? Or are there 
other/easier ways to reuse place states? I somehow like the idea of having a 
more general place that stores the general state and multiple more specific 
places that only stores the specific state but also have access to the 
general state they need.

Thanks in advance for any helpful thoughts.

-- J

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Aw: Re: Activities & Places, token question

[Jens]

Am Freitag, 13. Mai 2011 15:28:28 UTC+2 schrieb Thomas Broyer:
>
> ...and because an empty @Prefix is simply ignored when generating the 
> token, you could have /#contactus that way.
>
>
 But you can only have on PlaceTokenizer with an empty @Prefix. Just keep it 
in mind if you now think you could do /#contactus and /#impress with two 
places and both tokenizer have an empty @Prefix. You will get an exception, 
at least thats what me happened yesterday.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Activities & Places, token question

[Thomas Broyer]

First, you could use the empty string instead of a "random token", and it 
would give you a /#ContactUsPlace: token.

There's also the possibility to either put a bunch of "places" into a single 
Place class, and using the "token" to disambiguate them (e.g. 
/#CommonPlace:ContactUs); or you could instead use different Place classes 
but a single PlaceTokenizer (better IMO) with the same results.
...and because an empty @Prefix is simply ignored when generating the token, 
you could have /#contactus that way.

Finally, but you shouldn't need it for your use case, you can provide your 
own implementation of PlaceHistoryMapper instead of relying on the generator 
(you'd lose all the magic related to @WithTokenizers and @Prefix though and 
have to do it all by yourself).

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.