: Jay Fields
Since views are templates they can also contain behavior. The most common behavior you encounter in a view is formatting; however, since the view is a template you will occasionally see computations or worse. Because this logic is stored in a template it can be problematic to test. Presenters address this problem by pulling all formatting, computation, and any additional behavior into a class that can be easily tested.
This is a common problem for me especially when dealing with view components that are reusable but where their presentation is completely dynamic. Take a view component which has multiple drop downs, but depending on data from the model, certain drop downs need to be presented horizontally or maybe not presented at all.
If PureMVC used Presenters, then that would mean anyone wanting to use your component needs to be using PureMVC.
My original thought was that it seems as if though it would be a great way to add another layer between the Mediator and the components themselves, thus making the components dumber, i.e. more reusable.
However my colleague argues that this is less cohesive and that you are indeed right in the sense that if the view components relied on a presenter to be displayed properly, then without their presenter they are not as powerful and less portable to other applications.
How would one go about solving this problem in the PureMVC world? I was even dreaming of a LayoutMediator utility that would extend the Mediator and allow for multiple layouts of its view component. It could have a default layout when registered and the ability to specify different layouts for different instances.