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 ?! -- 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/-/TZem1DCrJiAJ. 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.
