Inherited Classes and Dynamic Views in PureMVC (AS3)

Question

I was wondering best practices for views of inherited classes in PureMVC in this situation:

• Multiple classes inherit a BaseClass (lets say InheritedClass1 and InheritedClass2)
• Each InheritedClass has a respective view (derived from a base view class, but each unique)
• With a given dataset (lets say ArrayCollection of InheritedClass1/2 Objects), the respective views need to be dynamically loaded.
• The dataset is relatively large, so a TileList would be nice (since it only instantiates objects which are currently displayed)

I can think of a couple solutions, but I find them to be too "hackish" to be the best solution:

• In View: Repeater over a BaseClassView which attributes a view to a State (set to the "InheritedClass1" state to add a InheritedClass1 object) Pros: No unneeded memory increase (States' objects are instantiated when needed) Cons: View is dependent on the data types, so adds coupling

• In Mediator: Loop over the ArrayCollection and addChild() the views based on data type Pros: Works. Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View. Slower than a Repeater.

Any comments or other suggestions would be appreciated. Thanks!

Answer 1

The answer is simple if you like the first example. Why not have a map (Object()) on the mediator that assigns datatype to view component (or states). e.g.:

private static var map:Object = {"ic_oneType": "ic_oneState",
                                 "ic_twoType": "ic_twoState"}

And the mediator can assign that map to the BaseClassView.

I'm likely to agree with the idea that you need some form of viewProxy that renders all your inherited views based on data fed to it from the mediator (e.g., first example). Can confirm or deny whether states is the best course of action in your UI though without more concrete examples.

Answer 2

Mediators are part of the View. How would you separate them from the View is beyond me.

I'd got with option 2.

Here's a topic from the pureMVC forum: Dynamically adding View components: where should I do it?. The post by "pureMVC" should be of interest to you.

Also, the size of the dataset can be problematic. If it's really large you should consider using a List with renderers instead of adding a component for each item (repeaters do that). Which would further complicate things a bit because you'll have to wrap your data to keep the main component decoupled of the Model.

Answer 3

Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View

Not really: they're what the documentation refers to as a collaboration pair and should be treated as such.

Answer 4

Cons: View is dependent on the data types, so adds coupling

Typically, a view component has no other purpose than to display the domain data and possibly allow the user to interact with it. It is a given that the view component will need to have some understanding of the domain data.

So feeding a collection of VOs to your view component doesn't add a 'bad' coupling. A 'bad' coupling is when the view component knows about how to reach into the Model tier and manipulate the Proxy that holds the data. Or when the Proxies in the Model tier know how to get their hands on the view components or their Mediators to poke data into them.

Mediator is adding things to the View, which defeats the point of the separation of Mediator and View.

As Coded Signal pointed out, we're not trying to separate the Mediator from the View component. The Mediator is the one actor in the PureMVC system that should know the view component, and mediate the communications between it and the rest of the system. The Mediator is the most critical actor in the system with regard to loosening the coupling between the View tier and the Model tier.

To communicate with the view component, other actors send notifications, which the Mediator hears and responds to by manipulating the view component's exposed API; spoonfeeding it data or invoking methods on it. This effectively keeps the rest of the app from needing to know anything about the component.

The Mediator also listens to the component for events and acts on its behalf, retrieving data from the Model tier, or sending notes to to other Mediators or to trigger Commands in the Controller tier. This keeps the component from having to know anything about the system it is connected to. It simply exposes an API of properties and methods, encapsulates its own behavior and sends events when things happen that the system should know about.

So together, the Mediators and View components make up the View Tier of the application.

-=Cliff>