On Friday, November 18, 2011 11:12:58 AM UTC+1, Andrew Uglev wrote:
>
> Hi! I read a lot about MVP, tokens, places but still newbie and need
> an advise about complex token strategy.
> For example I have a Book object (that has its activity, place, view).
> The book can be shown, edited and commented by its ID. The token need
> to be switched to smth like
> #bookPlace:234/show
> #bookPlace:234/edit
> #bookPlace:234/comment
>
> Switching to edit and add comment need to be done without reloading
> object (I mean that something like getPlaceController().goTo(new
> BookPlace("edit")) will reload the object)
>
It only reloads the object if your code reloads the object. It depends
whether you reuse activities and/or switch their state "on the go", and
whether you use some kind of caching for your objects.
You could, for instance, return the very same activity instance but switch
the activity to an "edit" (or "comment", or "view") state depending on the
place. I wouldn't do that because it adds state to the activity, which can
lead to complex activities that are hard to test and to maintain.
Or you could simply use some caching for your objects, so that even if you
start a new EditBookActivity you can use the same Book instance as the one
you used second before in the ViewBookActivity, without reaching the server.
For my part, I'd reload the object from the server (to have the freshest
possible data), until it's proved to be a performance issue that needs
solving; and then only add some caching or use more complex activities (how
about a BookActivity that "wraps" the previous ViewBookActivity,
EditBookActivity and CommentBookActivity, to switch them –mimicking an
ActivityManager, re. activities' lifecycle– easily while providing them a
cached Book entity?)
That's what we're doing ATM, and we haven't heard any negative feedback
about performance (actually, even if that was the case, we couldn't do much
about it, because going from "view" to "edit" in our case involves making a
"checkout" and a lock on the server-side: the entity is either in "view" or
"edit" mode, which drives the UI; it's not just a UI choice).
> To switch to "comment" state of book's view without reloading I'm
> trying to use
> History.newItem(History.getToken() + "/comment", false); // token
> goes to #bookPlace:234/comment, the view displays comment input form
>
> To properly display #bookPlace:234/comment token In the Book activity
> constructor I need parse the token using something like:
> String[] tokenPath = place.getPlaceName().split("/");
> this.bookID = tokenPath[0];
> this.action = tokenPath[1];
>
> Are there some helper classes to parse and map complex tokens?
No, but the parsing should be done in a PlaceTokenizer, not in activities.
Your BookPlace should have two fields: bookId and action, and its
PlaceTokenizer builds a <bookId>/<action> token and similarly parses it.
You activities just see a BookPlace with two fields.
That way, you can easily change your tokens at any time (e.g. switch
<bookId>;action=<action> or <bookId>:<action> for instance), without
changing anything in your activities, only the PlaceTokenizer responsible
for the BookPlace. Separation of concerns FTW!
Apart from that, no, there's no helper class in GWT: you're free to use any
kind of token you want, and you're responsible for parsing and serializing
them to/from places.
> Am I
> right using History.newItem(History.getToken() + "/comment", false);
> to add "actions" to token?
>
No.
If you need to change place, use PlaceController.goTo.
If you don't want a new activity, have your ActivityManager return the very
same instance; that way it won't be onStop()ed and start()ed again, but
simply reused as is (it won't even be notified of the place change, listen
to the PlaceChangeEvent from within your Activity if you need to).
If you don't want to reach your server to get an object from its ID, use a
cache.
Using History.newItem that way, you're dependent upon your tokens' format,
and if you have another ActivityManager that would need to be notified of
the change (maybe you don' t have one right now, but you could have a need
later on), it won't be.
PlaceController.goTo is the way to go here.
--
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/-/JJcClisInRoJ.
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.
