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 <drgenejo...@gmail.com> 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment