from cliff
In the sense that the Model/ModelLocator is like a Christmas tree and we adorn it with all our cheery holiday data objects, yes the PureMVC Model is similar to the ModelLocator.
However it differs quite a bit in terms of how we actually access to the data.
In Cairngorm, typically you:
* Define the ModelLocator class as a Singleton.
* Add properties to it.
* Fetch the ModelLocator Singleton at various places in the View by calling its getInstance method.
* Bind to its properties.
Binding is something else that is very Flex/Flash-centric that was verboten to rely upon for the PureMVC implementation. In an environment that doesn't have the Flex and Flash classes, events and binding can't be counted upon being there there for you. At least not with the Flash/Flex implementations. (Think Mozilla Tamarin, or even J2ME, or maybe curl).
In PureMVC, you:
* Define proxies to hold the data
* Register them with the Model, typically via the Facade
* Retrieve the Proxies elsewhere with Commands or Mediators
* Set the data on the View Components with Mediators
Of course there's nothing to stop you from fetching the Proxies inside your View Components, and binding to their data. But that makes the View Components less portable since they now have this inherent PureMVC stuff in them.
Look at the Architecture 101 demos. All custom components have no knowledge of the PureMVC system or where their data comes from at all. This means you could carry them away and make a Cairngorm demo around them without having to remove any PureMVC framework stuff at all. Instead they expose an API to that their Mediators use to communicate with them, using public properties and Events. Internally they use binding all they wish to move data around and change their behavior based on the current data in the controls.
This is the path to reusability in View Components.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment