I'm trying to figure out how to make this parallel composite views / presenter hierarchies. And in my opinion it just break the MVP pattern.
One of the goals you pursuit with MVP is to decouple the View object from the logic it contains (the presenter). Making the Presenter unaware of how the view is actually rendered. And also implicitly by using the EventBus decoupling the presenters from the others. In the moment you have a 'parent' presenter, everything screw up: 1. The parent presenter has a knowledge of the children presenters. You may be attempt to move the logic relating the children (before in the event bus) to the parent presenter. Coupling them unnecessarily. 2. Worst. The parent presenter has good knowledge of the view he manages. The view needs to provide hook for the children. So the presenter can attach the views of it child presenters to it. Of course, it may be cases where having a 'Parent presenter' is a good idea. But I think of this cases where actually you make the separation for no conceptual issues (be able to reuse code, like you could do in a table, separating the rows as views). Maybe I misunderstood something here. But I think the 'guy' responsible for the layout can be the AppController. As in the first first part of the article states. 'The AppController is responsible to handle logic that is not specific to any presenter.' But I don't like to much the idea. It makes the AppController aware of the view and layout. But on the other hand it may make sense, he is already aware of the History tokens. And probably if you are also deploying for mobile devices you will end up you need to rewrite the AppController. Other idea I kind of like more. Is using this new concept of Activity (Google IO 2010, Architecture GWT) So each activity will be a "page" in the application. The AppController is listening the EventBus for events requesting a new Activity. Then the AppController load the new Activity and tells it to display the page. So basically splitting the AppController into Activities. What do you think about this? Are this parent presenters a good idea. Better to move them to other 'entities' like AppController or Activity? Thank you -Fran On Apr 25, 12:54 pm, interdev <[email protected]> wrote: > Thank you everyone for sharing. > > >@Chris Ramsdale, > >"We use the technique described in part II. Composite views are responsible > >for instantiating their own children, and making them available for the > >parallel composite presenters. " > >"Regarding the nested layer presenters, thanks for the feedback and I'll look > >into our codebase for examples that we can share publicly. " > > Chris, I was wondering if you can share any code samples, or if > possible ask google team > to write a tutorial on more complex layouts and navigation. (parent/ > child, composite views). > > I've visited many forums, and this has been an area where many are > struggling. TheMVPtutorial is great for introducing the concepts, > but > for real world applications with complex layout, i think more examples/ > resources are definitely helpful for those who want to follow best > practices. > > almost all GWT books are written prior to 2009, mainly dealing with > widgets, and very little on architecture, especiallyMVP. > > Thank You > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > 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 > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
