In our Flex projects we typically use the Passive View pattern ( http://martinfowler.com/eaaDev/PassiveScreen.html). Probably I should blog about my experience with this, but I am pathologically lazy and terribly selfish, so I don't have a blog. The applications I'm creating involve a lot of bidirectional server communication and real-time multiuser interaction, so using this pattern enables me to create View test doubles that use LocalConnection to communicate with a central admin testing flex app that runs test harness scripts. For example, a simple test would be: Have user 1 login, and make sure the name appears in user 2's screen. But we can essentially replicate arbitrary user interactions using this setup, and test the application end-to-end modulo Views. We can also substitute mocks for View classes to test the Controllers. I should mention that coding these mocks in AS3 is a bit of a PITA. Can anyone think of a way to create a flex mock test framework? Message me off-list please! Another advantage of this approach is that my View (i.e. MXML) classes contain very little code, just setter methods and calls to the Controller. That makes the software text for these less intimidating to graphic designers.
We are actually looking for someone to help us part-time with our Flex coding. We can only afford $20 per hour right now, but email me off-list if you are interested! We are making some pretty cool applications! Adam On 10/15/07, Paul Dale <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > >
