One other detail about our implementation: Because there is no dependency injection in AS3 (that I know of), I have an Abstract Factory generate the View components. This way I can just swap out my Abstract Factory with one that generates Mock Views for testing by altering a Boolean constant in the main startup class.
--- In [email protected], "Adam Duston" <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > > >
