How to handle dependencies in minor UI controls within the MVP framework.

[DrG]

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!

[jeff...@gmail.com]

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.

[Yuly]

Sometimes I use sending custom events (including parameterized, when
needed) to the presenter through HandlerManager.fireEvent(..). But
more often I prefer to keep a reference to the presenter in the view,
and my colleagues also think this approach simplifies the code.