Part 1 – Frameworks
Part 2 – Directory structure
Part 3 – Application and ApplicationFacade
Part 4 – Notifications, Commands & Use Cases
Part 5 – Model & Proxy
Part 6 – The Application View & Mediator
Part 7 – The Login View & Mediator
Part 8 – The Roster View & Mediator
Part 9 – The Chat View & Mediator
Conclusion, Demo & Downloads
We need to create a PureMVC-friendly folder structure for our application – right click on src and create org, then within that create davekeen, then within that create xiffer. This will be the base package for our Jabber client. Now we need folders for the various bits of our application. Within xiffer create three folders named controller, view, model and events. Finally within view create a folder called components. We should have ended up with a folder structure that looks like this:
Now is a good time to explain what each folder’s contents and functions are. If you haven’t already done so you should have a read through the PureMVC best practices and framework overview as it will make things a lot clearer.
This is the base package of our application and will contain Application.mxml (the Flex entry point) and ApplicationFacade.as (the PureMVC entry point). The rest of the application will be contained in the other folders.
The controller package contains commands which implement individual pieces of business logic. For our Jabber client this will be things like login, logout and send message.
The model package contains proxies which are the bits of code that do all the dirty work. All communication between our application and the Jabber server will happen within the proxy; in fact this is the only bit of the application that will even know that a Jabber server exists.
The components packages contains our actual MXML files – the things we’ll see on the screen. Cliff Hall has put a lot of thought into the design of PureMVC and these components know nothing about the framework or internals of our app. When things happen they dispatch events, and they might expose public methods which the framework can invoke.
The view package contains mediators which control our components. In some MVC frameworks this folder might contain the actual objects that are displayed (i.e. subclassing DisplayObject), but PureMVC adds an extra level of abstraction. The mediators know about PureMVC, but the components are completely self-contained and rely on their associated mediators to do any application-wide communication.
The majority of communication within PureMVC is done using notifications, but the only exception to this is communication from components to their mediators which is done using normal AS3 events. Its also perfectly acceptable to put this package within the view folder.