doing MVP outside activities/places - good idea? (or how to change place token without going to same place with changed token)

[tanteanni]

since some weeks or probably months i walk through gwt-mvp/activities/places-forest. i read/wrote many posts here and got many answers. at the end i desided to tried to separate MVP from activities and places (like thomas broyer suggested at many places). (for example here: here (second post): "Activities however are in no way related to MVP: you can use activities without doing MVP, and you can (and you probably will if your UI is complex) do MVP outside activities.")
my question is: is my interpretation of separating these concepts is ok and at least good (lately i stumbled across some difficulties). So what i did is to let one activity control/start many "presenters". Per place i only have one activity and one activity mapper. at first sight a very elegant and easy thing but first problems arise if i want to go to same place with some state change (reflecting user interactions in history). all example code i saw about this is going to another place (goTo(samePlace(butOtherState))) but this yields in starting the hole activity again (probably it's a chached activity - doesn't matter in my case).
Is there any way to keep on same place but change a token of this place? probably by implementing setToken on a place?! My activity would do something like this:
//instead of goTo(place)
private reflectstateChange(string state){

(castToMyPlace)placeController.getWhere().setToken(state);

}

Is this a good way to go? Or should i switched to presenters are activities style with many mappers like Mauro Bertapelle is showing in his very good example?

[Jens]

Take a look at: https://groups.google.com/d/topic/google-web-toolkit/OsDpLtBoTQo/discussion

I had nearly the same problem. Short version: If you have non singleton activities they will be restarted for every PlaceChangeEvent. If you want to avoid this you need to cache your Activity. But once you cache your activity if lives longer than its place it is started for. Thus the activity has to be notified once a PlaceChangeEvent occurs for the same place but with different internal state. This can be done by a method defined in every activity through a custom activity interface that extends Activity (e.g. setPlace() called by your activity caching code) or by letting the activity itself listen for PlaceChangeEvent and let the activity decide if it needs to update or not. That way you can always use placeController.goTo(new Place(new state)) to update the URL according to the current app state.

First I have used myActivity.setPlace() to notify the activity as I need this method anyways because of GIN. But that way you need an extra flag in your activity so you can decide if the activity is already running and you have to update it or if its not yet started and you can do the work once its started. So basically

public void setPlace(...) {

  //storing place information in activity variables

  //....

  //update activity/view

  if(isRunning) {

    doUpdate();

  }

}

public void start(...) {

  running = true;

  doUpdate();

}

So I prefer it to let the activity listen for PlaceChangeEvents. That way you won't need the extra boolean flag.

-- J.

[tanteanni]

thx!

absolutly the same ideas came to my mind and let me post this question. (i have to admit that not only thomas' but also your answers and suggestion directed me to this approach)

i read the discussion you mentioned above  and one question remains: is it a good idea to do "things" this way? my feeling is that the way mauro did it in "layoutMVP"-Example is the way the "GWT MVP Framework" implies?! or the other way around: what consequences to bear (beside the update state problem) if i go this way any further? (i am in the privileged position to could still do any refactoring)
for example what about activity methods called on place change like mayStop(), onCancel()... - mayStop should only be called if place changes (not only state)?! I also have a bad feeling about singleton activities (each one referencing some presenters). somehow i like the idea of disposable activities and presenters.
(having two people (you and thomas) doing it this way calms me down ;-) )

the advantage of activity=presenter/many activitymapper approach (imho please correct if i am wrong) is that you could choose caching per display area. so activities that shouldn't be restarted on "place change" will be cached via cached mappers, activities that should be updated on every place changed will be mapped via "normal" mappers and return new instances every time. So imho there is a solution for our problem by doing it the other way ?!