I think the principle of extracting everything that can't be expressed as a simple data binding is solid.
That makes it easy to inject a test data object (or series of data or data objects) to automate running through each presentation possibility. ...paul On 10/15/07, Bjorn Schultheiss <[EMAIL PROTECTED]> wrote: > > Hey all, > > I'm attempting to get a discussion going here on this topic since Paul > disabled comments on his blog. > > Is anyone else here reading this series? > > In particular his last post. > Supervising Presenter > http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_2.cfm > > One of the benefits he speaks about with using this pattern is, > Improved separation of concerns > Following the Supervising Presenter pattern should yield an > application-specific class hierarchy that is separated from the view > classes, but coupled to them. Common presentation concerns can be refactored > into Presenter base classes, and this should help to reduce code-duplication > and improve consistency across an application. > > This concern is of huge importance to me as a flex dev. > > During dev one of the main issues i run into is what will be an > 'application-specific view' as opposed to a 'reusable-component' as > abstraction can be a time-consuming exercise. > I've never been a fan of code behind but i think the 'Presenter' does > bring in a useful and easy to implement application level of abstraction > that can ease development. > > btw I also like his use of Binding. > > > regards, > > Bjorn > > > > >
