Given the presentation model pattern, is the view, presentation model, or model responsible for adding child views to an existing view at runtime?

Question

I am building a Flex 4 based application using the presentation model design pattern. This application will have several different components to it as shown in the image below.

The MainView and DashboardView will always be visible and they each have corresponding presentation models and models as necessary. These views are easily created by declaring their MXML in the application root.

<s:HGroup width="100%" height="100%">
    <MainView width="75% height="100%"/>
    <DashboardView width="25%" height="100%"/>
</s:HGroup>

There will also be many WidgetViewN views that can be added to the DashboardView by the user at runtime through a simple drop down list. This will need to be accomplished via ActionScript.

The drop down list should always show what WidgetViewN has already been added to the DashboardView. Therefore some state about which WidgetViewN's have been created needs to be stored. Since the list of available WidgetViewN and which ones are added to the DashboardView also need to be accessible from other components in the system I think this needs to be stored in a Model object.

My understanding of the presentation model design pattern is that the view is very lean. It contains as close to zero logic as is practical. The view communicates/binds to the presentation model which contains all the necessary view logic. The presentation model is effectively an abstract representation of the view which supports low coupling and eases testability. The presentation model may have one or more models injected in in order to display the necessary information. The models themselves contain no view logic whatsoever.

So I have a several questions around this design.

1. Who should be responsible for creating the WidgetViewN components and adding these to the DashboardView? Is this the responsibility of the DashboardView, DashboardPresentationModel, DashboardModel or something else entirely? It seems like the DashboardPresentationModel would be responsible for creating/adding/removing any child views from it's display but how do you do this without passing in the DashboardView to the DashboardPresentationModel?
2. The list of available and visible WidgetViewN components needs to be accessible to a few other components as well. Is it okay for a reference to a WidgetViewN to be stored/referenced in a model?
3. Are there any good examples of the presentation model pattern online in Flex that also include creating child views at runtime?

Answer 1

MVP is somewhat open to interpretation. I've written a large scale Flex 3 app with MVP so I'll give my input based on experience.

From the presenter's perspective it would be the view's responsibility to add subviews (because views are interfaced -- think console app replacement). Nothing view-specific should exist in the presenter (ie. you should be able to unit test it having a mock view).

You are correct, the main view shouldn't be doing this either.

The presenter for that view would assign a WidgetPresenterCatalog (populated elsewhere in the application based on business logic) that the view can choose from. The view would delegate all widget presentation, selection, and interaction to your DashboardView component. That component selects from the catalog and displays them.

Problem #2 - how to display them! The same way you connect a presenter and a view. You have a class that knows how to couple a presenter and view and return the view for presentation. Again, the presenter would pass this to the MainView and the MainView would provide it to the DashboardView.

Now your MainView and Presenter should be ultra lightweight and the widgets have very little surface area on them.

Answer 2

Per Martin Fowler's explanation of the Presentation Model ( http://martinfowler.com/eaaDev/PresentationModel.html ), I believe the answers are as follows:

FWIW, I'm not an expert in the Presentation Model pattern.

1) Would be in your DashboardPresentationModel since that holds the presentation logic for your program. That logic would then determine whether the widget is allowed or not, as well as making the subsequent instantiation.

2) If I understand your layout correctly, then I believe the answer is no. The PresentationModel should contain that information and, if necessary, provide methods for accessing that information.

3) Sorry, don't know.