PureMVC Tutorial – Flex, PureMVC, Jabber and XIFF 3: Part 2 – Directory structure

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.

Onto part 3…


  1. hi dave

    just want to clear some thing ( “right click on XIFFer and create org” ) if i follow this start i well and up w/ this


    w/ is wrong.. right? because this should be like this


    org should be inside src folder right?

  2. Hi Dave,

    The tutorial is great. Thanks! I just happened across this while looking for info on purmvc. More than you’re tutorial, I love how you interact with people who comment. Every question has a response… that’s frickin’ crazy. You make me want to re-read every Dale Carnegie and John Maxwell book. You truly are contemporarily-charismatic (creative commons mapDev). Cheers. You’ve got me hooked.

  3. Hi Dave,

    AS3 events are related to the View tier so I would put ‘events’ folder into a ‘view’ folder.


    Mariush T.
    Freelance Flex Developer

  4. Hi Maruish,

    Officially speaking you are quite right – AS3 events are only used for communication between the view and mediator so they do belong in the view folder.

    However, have a quick read of the end of part 7 of the tutorial. After lots of development with PureMVC I have found that it is very often the case that the parameters I need to pass to a command are exactly the same as the attributes within the event that triggered it.

    For example, clicking ‘Login’ in the login page dispatches an event LoginViewEvent.LOGIN with attributes ‘username’ and ‘password’. This gets picked up by the associated mediator which then dispatches a ApplicationFacade.LOGIN notification which triggers LoginCommand. And what parameters does LoginCommand need? ‘username’ and ‘password’, of course; exactly the parameters within the event. Therefore rather than creating untyped objects or extra value objects I opt for reusing the event class for the commands themselves, and this is the reason why the events folder is at the top level rather than in view.

    I am fully aware that it can be argued that this breaks encapsulation, but I’ve never really seen a practical downside to this approach (so far!) and I think the benefits far outweigh the extra hassle of creating redundant objects to pass to commands.

    Hope that makes sense!


Leave a Reply

Your email address will not be published. Required fields are marked *