@isragaytan

Thanks! I'm really excited about presenting at MAX! Been practicing a lot so hopefully it all goes well and we'll have more people involved with PureMVC and the community!

@Cliff

Come on man, what's the hold up with that announcement on this on the main page!? Adobe MAX starts this Monday!

@Jason,

Sorry, I would have replied sooner but for some reason I'm not getting email notifications on replies. If you will be attending the Flex Frameworks session please be sure to stop by and say hi afterwards! Would love to meet and talk PureMVC. Yeah I was there to present on Kindling but you probably spoke with the Ribbit guys. Either way we'll see one another after the frameworks session. Hope you like it!

I'm very excited to announce that Cliff has recommended me to present on PureMVC at Adobe MAX this year at the Flex Frameworks session which will also include Mate, Swiz, and Cairngorm. He's not able to make it this year but I'm happy to take his place and represent an excellent framework and community at MAX! I love presenting so I'm hoping to give a great impression on PureMVC!

I really want to include everyone's feedback into my presentation. I'm currently on vacation but I will be planning it out as I have a strict time limit of 45 minutes and its supposed to be a hands on session. I'd like to ask you guys a few questions to help me organize what parts I cover and in what order.

Again note that this will be a near complete hands on session so all of the questions asked below are in regards to having the attendance code out the sample application.

• What part of PureMVC do you find the hardest to understand?
• If you were introduced the parts of PureMVC (mediator, facade, etc) what order do you think is appropriate?
• What piece (mediator, facade, etc) do you think should be covered more thoroughly over others? This will have a great affect as there is a time limit of 45 mins.
• Anything you'd like me to share about the community? I personally think this is one of PureMVC's strongest areas
• Are their particular points from the PureMVC Best Practices documentation that you feel should be in the presentation?

I think so too especially if you are working fully in Flex. The best practice that Cliff has outlined is great if you are really working across various projects in various languages and honestly just want to follow the best practice. Since I work with the Flex framework (and dig through the source very often!) I'm used to the way they do packages so I prefer that. Whatever works for you, use it well!

The argument for me would be is if you really want anything organized by a root model, view, and controller directory. Personally, I don't see the value in that. I've tried it and found it to be much more work but then I work pretty much 100% with Flex so I'm very used to how they do things and have applied their packaging practice. I think this is most valuable for my projects since knowing Flex is a requirement and by knowing it anyone should feel just comfortable with the structure. My argument for how I do packaging is each package has its own unique set of classes. PureMVC defines its own classes for the view, model and controller so I'll have those classes there. For example, my projects would be like:

• com
  
  • arc90
    
    • myApp
      
      • controller (contains only Commands)
      • model (contains only Proxies)
      • view (contains only Mediators)
      • enum
      • delegates
      • utils
      • containers
      • controls
      • core

I've found it much more maintainable this way when I have one package I open I just see those specific files, rather than that and 20 or 30 others.

To add on what Cliff said its also not only for reusability. A lot of people get tripped on this. It's not so much about reusability as it is flexibility and maintainability. Those are key. If you have a good separation between your view component and mediator maintaining the "simple" view component API then you can change the view component completely and not have to change a line of code in your mediator. This is crucial because your views will change often! No requirements come in, new releases, features, etc. I can't tell you how important that has been for me as I've seen firsthand with hard deadlines making drastic changes to a view component the night before a company presentation and not having to change code elsewhere. Encapsulate that view logic in your component and you'll reap the benefits down the road. There is a reason why you put a bit more effort up front.

Sammi, I agree. I found that out very quickly that I really didn't like that setup. It creates way to much hierarchy and sometimes doesn't give the organization I want. Since I use PureMVC with Flex/AIR projects I've been following (and others where I work at) the Flex framework way of organizing components. I define a "model", "view", and "controller" folder and the only contents of those folders are the respective PureMVC actors: Proxy, Mediator and Command. So when it comes to views I use packages like: "controls", "containers", "utils" for utilities, etc. I've found this setup much more productive and offers me more organization without the deeply nested folder hierarchy.

I on the other hand are not so afraid of such a small man and pestering him about a release date! Cliff, it's already slightly past the middle of May. Any release date on that demo? Don't mean to be pushy but just as you have said the startup process is an area I've struggled with too.

I'm curious if anyone here has any utilities or approaches they use to handle loading data dependencies at startup. By that I mean making any service calls and waiting for them to complete before any interactions with the app can take place. I use the AsyncCommand utility in my app but its not what I'm looking for in this case since I'm loading dependencies in parallel (not in sequence, each call isn't dependent on one another).

Currently, what I do is have a command called CheckDataDependenciesCommand that fires any time one of those service calls completes. This is nice and simple but I need to handle failures and would like to enable retrying a service call a number of times if it has failed. I'm thinking my simple approach won't really do the trick and maybe a utility is better suited.

Thoughts or suggestions?

You always know how to save the day Cliff! Thanks again! The points you made really helped out and in this case makes sense to centralize it there.

Cliff, I've been really struggling with this lately and am wondering if you can expand on this point. I have logic that usually happens in a Mediator in regards to a component (saying moving a tab from a TabNavigator) and some other stuff like de-registering a proxy and or mediator. Since I want to have this in a command for reusability (I need this since it can be called from multiple places, keyboard shortcuts, buttons, etc.) how do you get around retrieving a mediator and accessing the viewComponent?

For example, I have a tab based interface for easy multi tasking. I can open a UserProfile tab and a second one for another user and edit or view both at the same time by switching between them. The problem I have is when closing it its not so simple as removing the tab from the TabNavigator (usually handled by an ApplicationMediator or mediator for that component, depending on complexity).

In a CloseUserProfileCommand, I would want to remove the userProfileVO from the UserProfileProxy collection, de-register the mediator (and any other child mediators), etc. etc. but I'd like to keep the removal of the child tab in that command as well, keeping everything in one place. Do you have a suggestion for this type of view logic and whether being in a command or not? Maybe some examples of situations you've run into and how you approached it?

Regarding packaging I've never liked the PureMVC standard of throwing everything in a high level model, view and controller packages. It's to limiting and I prefer much more organization. If you are building Flex and AIR apps I highly recommend following the Flex package naming. I find myself having much better organization this way and helps others jump into my project since if they know Flex I follow the same standards (ASDoc, naming conventions, etc.).

PureMVC does a great job defining the view, model and controller with the following patterns: Mediator, Proxy and Commands. So in the view folder I would only have mediators, in the model only proxies, etc. I then break up my components into other more meaningful named packages such as "containers", "controls", "utils", "core", etc. I've found this immensely useful and much easier to work with at one level. Hope this helps.

Agreed with Joel and Cliff. I actually use the same approach for filtering/sorting. I'll have say a TaskProxy where I maintain a collection of tasks, allow creating, updating, etc. My service interactions are maintained there. But the way I filter the data is very unique and doesn't necessarily match or behave with explicit fields. I like having this in its own proxy, TaskFilterProxy in this case, since it can change (new filters, changing others) and its important enough to have on its own.

Also I would store the current filter/sort selections in the TaskFilterProxy much like how you would store the search params in a SearchParamProxy. So I would have selectedFilter and selectedSort properties (thanks to Cliff for this tip from meeting you at MAX)! At the end of the day someone needs to be responsible for globally maintaining a selection so in my case the best choice was the proxy (or at least it made most sense there). This proved incredibly helpful since I have a single command FilterTasksCommand encapsulate the necessary logic (command doesn't receive any body, then it assumes current selection for filtering, critical if your app does refreshing behind the scenes!).

Hey don't be greedy! Share what you found with the rest of us that don't really much about it!

From what I read PureMVC Studio will have code generation. I'm not really sure of the details but I know their is some sort of drag and drop UI for setting up your PureMVC app. It should be a great tool!