On 21 août, 20:13, Patrick Julien <[email protected]> wrote:
> I've been experimenting with PlaceHistoryManager and company. So far,
> I have the following comments:
First, I've only read through the design-doc Wave and the code, I
haven't yet experimented with it (as I first have to migrate my
project from M2 to M3)
> 1. The tokens are big, they include the full path to the class, so all
> packages and the name of the class. It's a lot. In our case, it also
> exposes the name of the contractor to the user of the application.
This is only the "default" Proxy{,List}Place.Tokenizer
implementations; I put "default" between quotes as it's not even a
default, you have to *explicitly* use the tokenizers (the scaffold app
does this implicitly by using a PlaceHistoryHandlerWithFactory which
analyzes the so-called factory class looking for methods taking no
argument and returning PlaceTokenizer instances).
It looks like you're absolutely free to use any PlaceTokenizer
implementation you want, even with the stock Proxy{,List}Place places.
> 2. Tokens in RequestFactory only work with Record based classes. I
> think that's a shame. Will another facility supplement this? Because
> if tokens from gwt will only support Record, why even bother with
> ProxyPlace? Just make a goTo method in PlaceController that takes a
> record. I would prefer to have tokens for a place directly. I think
> that can be accomplished by having multiple place tokenizers however,
> one per place.
I don't understand. Of course RequestFactory only deals with Records,
but that's totally independent from Places and History tokens (well,
RequestFactory can give you tokens for your records, but yet again,
that's only if you *want* to use that, which you'll do by using the
provided Proxy{,List}Place.Tokenizer).
I haven't seen any limitation in PlaceHistoryHandler forbidding its
use with places other the the provided Proxy{,List}Place; of course,
for those places, you'd have to provide your own PlaceTokenizer.
> 3. Ultimately, I don't think the assumption that a record type is 1:1
> to an activity. The mapper stuff allows for this but is yet more
> code.
There's no such assumption AFAICT. And actually, for a given record
type, ProxyPlace gives you 3 different places, and ProxyListPlace an
additional one. You're then free to map those places to activities in
your ActivityMapper. And of course you're free to not use Proxy{,List}
Place at all.
> 4. It's a lot harder than it seems to always have a record ready to
> go. Especially coming from gwt-presenter were we always try to just
> keep a numeric id.
I don't understand. (maybe because I don't know gwt-presenter? but the
last time I looked at it, I really disliked its implementation of
places; it didn't "get" the concept IMO)
> 5. I think the Place class getting support for a collection of arguments,
> i.e.,
>
> setArgument(String, String);
> String getArgument(String);
> clearArguments();
>
> and more importantly, parseArguments(String s); so that we can pass in
> a string from the PlaceTokenizer.getPlace() after we've removed the
> prefix would be most helpful and be applicable to most.
Please NOOOO!!! That's the role of the PlaceTokenizer. If you want a
generic place with String "arguments" and a generic tokenizer making
look like e.g. a query-string in history tokens, you can do it already
but please don't make it a default!
You shouldn't do getArgument("foo"), you should instead have a
specific Place subclass giving you a getFoo().
It may sound a bit harsh but you've IMO been very badly influenced by
gwt-presenter.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
