I have used both methods in my app, if the interactions are simple like responding to a click then handling it in the parent presenter is fine but if there are many operations possible then it is worth grouping them into a helper.
On Jul 26, 5:35 pm, DrG <[email protected]> wrote: > I aim to have a discussion on best practices with regards to the MVP > framework and minor UI Controls. > > Imagine a typical MVP entity in your application where the view element is > made up of many interesting UI controls. Some UI Controls contain further > UI controls as the application is re-factored to contain each element in its > own logical class. > > I have taken the presenter component to mean that all logical operations of > the application should take place in the presenter so therefore any events > that occur in the sub-sub UI controls should be wired back up to the > presenter. > > I have a problem with this type of working in that imagine a click event, > the parent UI has to handle that, then that is passed to another parent and > then finally to the presenter where the click event is analysed and acted > upon. I would much prefer a scenario where a, say for example, a > navigationHelper dependency is injected into a view control that requires > it, thereby it can be acted on immediately without having to wire up through > the UIs to the presenter. > > I wonder if anyone had any thoughts on this as to the best practices in this > scenario. Or should all controls in the application be created in the MVP > style so that each object no matter how insignificant always has a presenter > associated with it? > > Any thoughts are much appreciated! -- 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.
