a well written post. Fowlers sync concerns are not especially relevant in flex with the data binding mechanisms we have at our disposal. from where I am standing the supervisor controller and a presentation model seems a decent approach. My reasoning behind this is that views render aspects or transposed "views" of the domain model, if the presentationModel then had to have all the implementation for handeling user gestures it quickly becomes a more complex class than it needs be. Seperating into a supervising controller to handle user gestures (and observe the domain model), which in turn sets the presentation model allows you to swap out both presentation model (another view onto a data set) and the supervising controller (different application actions from the same user gestures) more easily.
it allows becomes more testable as I really only need to test the superivising controller and see what changes were made to my presentation model (or domain model/application state) and on the presentation model level the different views onto the dataset. an approach i use a lot involves binding the views "currentState" property to my presentationModel, thus allowing me to test "viewState" as well and not only the data and the user gestures. Of course this fails if the state is not implemented correctly in the view. Here I can however see a good workflow improvement in gumbo as states and skins are externalised into the skin file, which I think would lead to views becoming evening thinner and thus more easily generated and less likely to change. your extension points then reside in the skin file, the pres model, the supervisor controller (2 of which are unit testable) and what ever domain structure you want to have behind this. A concern that has been raised in our team around this however is the extra code (thus footprint and increase in bugs), but unit testing obivously alleviates this concern and as a bonus a proper planning phase and generated scaffolding would really remove the issue, it does have some limitations in software which grows organically as it would most probally lead to a fair bit of refactoring (which is not a bad thing). All in all I think you guys have summed up testing really well, but something I find lacking in most flex related TDD posts is a discussion of the tools people use to make life easier, determine coverage, approaches around CI. There are some great tools out there (although I have yet to see someone run (what I would call) a proper CI enviroment with Air). That said, I have delved a fair bit into Jet transformations to scaffold, but in a true agile enviroment Jet still fails with mxml (I do think this is fixable). johan On Fri, Dec 19, 2008 at 9:17 AM, Errol Thompson <kiw...@acm.org> wrote: > > You mentioned Supervising Controller by Martin Fowler; > > did you know he has another variant of that same idea > > called Presentation Model? > http://martinfowler.com/eaaDev/PresentationModel.html > > Fowler describes four different patterns which he regards as different ways > of implementing the MVC or MVP patterns in his GUI architectures article > http://martinfowler.com/eaaDev/uiArchs.html and supporting articles > (Separated Presentation > http://martinfowler.com/eaaDev/SeparatedPresentation.html, Presentation > Model, Supervising Controller > http://martinfowler.com/eaaDev/SupervisingPresenter.html, and Passive view > http://martinfowler.com/eaaDev/PassiveScreen.html. > > My interpretation is that he sees the Separated Presentation as being at > the > heart of the MVC concept. He has retired the MVC pattern in his thinking > since he sees different forms of implementation. He sees this pattern as > separating the common functionality from the view specific functionality. > > The Presentation Model he argues is the beginning of the shift from MVC to > MVP although he contends that the boundary is unclear. He says that the > presentation model is a class that contains "all the data of the UI window, > but without any of the controls used to render that UI on the screen." In > effect, it separates the view from the data needed to build the view. > Fowler > talks about problems in synchronising the presentation model and the view. > > The Passive View sees the manipulates the view as well as being a > presentation model. This approach sees the view having no built in > functionality and the controller or presenter manipulating the view to make > changes. The controller pushes data back into the view. > > The Supervising Controller is similar to the passive view except that the > controller doesn't push data back into the view. This is left to data > binding mechanisms. The model in this pattern may be closer to a > presentation model rather than a domain model. The controller handles all > user gestures. One of the things with this pattern is that because the > controller and model have no knowledge of the view, it is easier to > implement in a test driven fashion. > > I believe one of the points of difference between the patterns is the > degree > of relationship between the view and the controller. In MVC, the controller > focused on handling user gestures and manipulating the model. The view was > left to look after itself. The presentation model was an attempt to > recognise that the view actually had model elements that could be used with > alternative views. The passive view proves difficult to test as you have to > mock out the view. The supervising controller removes all links back to the > view making it easier to build tests. > > --------------------------------- > Errol Thompson > Kiwi-ET Computing Education Research > Wellington, New Zealand > Phone: +64 21 210 1662 > E-Mail: kiwiet (at) acm.org > kiwiet (at) computer.org > Web: www.teach.thompsonz.net > --------------------------------- > > > -- j:pn \\no comment
