Correct methodology to update browser url with MVP

102 views
Skip to first unread message

Joel

unread,
Jul 8, 2013, 12:38:29 PM7/8/13
to google-we...@googlegroups.com

We are using the MVP pattern, and have a page with a selectable list. Each time an item is selected, we would like the URL to reflect the selection. Initially, the code used placeController.goTo() whenever an item was selected. However, we did not expect the activity's start() method to be called since its the same activity.

Right now, that code is a bit heavier-weight (reloads the list) as I believe is expected to be the case with activities. Is there a way to refresh the URL without the activity being recalled, or is there a different way we should be going about this?

Looking more for thoughts on methodology than a quick-fix... or maybe something is amiss about the start() method being called?

Thanks,
J

Jens

unread,
Jul 8, 2013, 1:07:45 PM7/8/13
to google-we...@googlegroups.com

We are using the MVP pattern, and have a page with a selectable list. Each time an item is selected, we would like the URL to reflect the selection. Initially, the code used placeController.goTo() whenever an item was selected. However, we did not expect the activity's start() method to be called since its the same activity.

Right now, that code is a bit heavier-weight (reloads the list) as I believe is expected to be the case with activities. Is there a way to refresh the URL without the activity being recalled, or is there a different way we should be going about this?

You can use GWT's FilteredActivityMapper to transform ItemPlace(<selected item>) into ItemPlace(<nothing selected>) and then use GWT's CachingActivityMapper to return the same activity if the place hasn't changed (determined by currentPlace.equals(newPlace), thats why you transform all ItemPlaces into equal ones using FilteredActivityMapper).

As the activity instance now lives longer the activity probably needs to listen for PlaceChangeEvent's, so you can select the correct item in the list if the user uses back/forward buttons of the browser. Activity.start() will only be called again if you navigate away from ItemPlace and then revisit it.


-- J.

Thomas Broyer

unread,
Jul 8, 2013, 6:04:52 PM7/8/13
to google-we...@googlegroups.com
What Jens' answer is implying is: if your ActivityMapper returns the same Activity instance (same instance, comparable to the previously returned instance with == ) then it won't be stopped/started by the ActivityManager. FilteredActivityMapper and CachingActivityMapper are there to help you set up such a thing without worrying about caching the activity from within your ActivityMapper, but you can also do it yourself by hand.

Joel Trunick

unread,
Jul 9, 2013, 10:48:41 AM7/9/13
to google-we...@googlegroups.com
Something odd happens when I use goTo()... The list (a CellList), will scroll so that the selected item is at the bottom of the screen. I have no scrolling code, and I don't understand why goTo() makes this happen. I'm even checking if the item has been selected and not reselecting it.


--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/LVwCEAy-o0s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Thomas Broyer

unread,
Jul 9, 2013, 11:31:53 AM7/9/13
to google-we...@googlegroups.com


On Tuesday, July 9, 2013 4:48:41 PM UTC+2, Joel wrote:
Something odd happens when I use goTo()... The list (a CellList), will scroll so that the selected item is at the bottom of the screen. I have no scrolling code, and I don't understand why goTo() makes this happen. I'm even checking if the item has been selected and not reselecting it.

It could be a side-effect of re-focusing the CellList…

Joel Trunick

unread,
Jul 9, 2013, 2:17:41 PM7/9/13
to google-we...@googlegroups.com
If its a re-focus effect, what would be the cure?


--

Thomas Broyer

unread,
Jul 10, 2013, 4:57:39 AM7/10/13
to google-we...@googlegroups.com


On Tuesday, July 9, 2013 8:17:41 PM UTC+2, Joel wrote:
If its a re-focus effect, what would be the cure?

Track its provenance and avoid it (if possible; hard to say without knowing why the CellList is re-focused)
 


On Tue, Jul 9, 2013 at 10:31 AM, Thomas Broyer <t.br...@gmail.com> wrote:


On Tuesday, July 9, 2013 4:48:41 PM UTC+2, Joel wrote:
Something odd happens when I use goTo()... The list (a CellList), will scroll so that the selected item is at the bottom of the screen. I have no scrolling code, and I don't understand why goTo() makes this happen. I'm even checking if the item has been selected and not reselecting it.

It could be a side-effect of re-focusing the CellList…

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/LVwCEAy-o0s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

Joel Trunick

unread,
Jul 10, 2013, 10:46:01 AM7/10/13
to google-we...@googlegroups.com
That is the odd thing, we don't have any code that focuses explicitly, or even manipulates that part of the screen (as checked through the debugger).

Even more strange is that our custom place controller has an effect on the behavior of the list. If we do a security check in "OurPlaceController", which is a REST callback (we do the goTo() call in the callback), the list will actually not show the selected item (it will be scrolled out of view). If we do the goTo() straightaway (no callback), then the item does show up in the view, but is moved to the last position on the screen/list. Again, we have _no_ scrollTo() calls or explicit refresh/reloads, that occur after the goTo().

Interestingly, if I put a Window.alert() right after our goTo() (from our activity, not our placecontroller), then I can see the item selected in yellow, it doesn't change to the default blue until after I click the alert okay button. I suspect something is going on there and some race condition with "OurPlaceController" logic.

We've had 3 developers look at this, and have been puzzled by it. This probably isn't a lot to go on, but I suspect it would be very difficult to reproduce with a simple example. Any thoughts appreciated.








To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages