Really, I wanted to wait until we had a production example of the Flex no-framework perspective, but I’m sure it could be an interesting talk nonetheless. We’ve got enough sample material to make the point.

And as I’ve said in the past, I’m not sure I want to be the Flex version of Simon Horwith…

- max

Yes, we looked at MG:Flex and liked it a lot, but last time I checked it was still in alpha 1.

We just built a small Flex app using our “Flex only” theory of development, and it worked great. We just used the event/component/binding model in Flex with simple, standard OO design techniques (layering, listeners/observers, and all that fun stuff); no framework required.

The only thing we have identified so far internally as a possible need for a framework so far is global event handlers, which PureMVC does very nicely. We’re using PureMVC on a mission-critical application that we expect to go in to production in Q2/Q3 of next year. We define a global event handler as a case where you have multiple components that you want to react to an event. PureMVC handles this neatly with its notification system. This would be harder in MXML or AS without a framework, since you would need to roll your own code to have interested parties register interest in an event. Doing this while keeping the components involved blissfully unaware of each other would require similar code to the stuff already in PureMVC out of the box.

Of course, this isn’t a terribly difficult thing to achieve. We have another mission-critical application just kicking up official development after a long PoC phase, so we’re going to try to tackle the global notification scenario again using traditional OO techniques and the built-ins in Flex. I’m definitely going to publish our findings when we’re done, including sample code, since Flex frameworks (or the lack of need for them) seems to be a hot topic in the Flex community at the moment (see my recent post on “Cairngorm Bad“). :)

We’re really interested in PureMVC at CFI, which led to my analysis of the sample app. I’m glad to see some other frameworks popping up besides Cairngorm, for obvious reasons. It will be nice to look back in a few years and see where the Flex community stands in terms of frameworks.

As you probably read on my blog, I’m going to be experimenting with a collection of things that I consider my favorite items from each of the popular Flex frameworks, and trying to hobble together something. It might end up being a framework, it might end up being a set of practices for Flex development, or (most likely) it will collapse under its own weight and I’ll enjoy the knowledge gained. :)

In any event, I’d love to hear your thoughts as I progress (I may even start posting some code soon), especially with the professional experience you have and your experience building a framework so far.

The documentation you’ve provided on the PureMVC web site has been very helpful with my understanding of the framework. I’ll be taking a look at the Best Practices document as you suggested.

Cheers,

- max

Good to see you had a close enough look at the PureMVC framework to make good and pointed comments like:

—-%snip%—-
In AppControlBarMediator’s constructor, there are three lines of code registering event listeners so that the mediator can pick up events from the AppControlBar. The AppControlBar then has to define specific functions to announce these events (another six lines of code). Once the AppControlBarMediator catches the events, it does nothing but invoke the appropriate proxy, but only after referencing specific properties of the AppControlBar using dot property notation.

Having discussed this with my buddy Russ at work (easily our most experienced Flex developer, and a very sharp fellow besides that), we agreed that using an event registration/announcement model would allow the AppControlBar component to be reused in other applications. I can see the point for completely reusable components, but this control bar is so specific to the application in question that all the event registration code seemed like overkill, especially if the mediator is just going to break the encapsulation of the component in order to get the properties to pass to the appropriate proxy.
—-%snip%—-

Here, you saw and described precisely the give and take of the of the Mediator implementation.

For this particular Mediator the listener / handler functions may seem overkill, but it was meant to demonstrate the most common idiom that will be used to couple the View Component to the Mediator, that is placing listeners on it, and acting as the mediator between it and the rest of the PureMVC system.

By doing this, the View Component can remain relatively free of code, which is a positive thing, because it helps separate the view definition (mxml) from the logic that controls it (mediator handlers). A big benefit is that that code may now be included in your ASDoc.

Yes, the Mediator ‘breaks the encapsulation’ of the View Component ( AppControlBar ), by looking deeply into it, but, as you say the two are, somewhat necessarily tightly coupled.

So, consider the direction of the coupling. If the View Component only raises events, then it is reusable in other (or may easily be ported from), non PureMVC contexts.

The Mediator assumes the sole burden of knowledge about this View Component, within the system. Other actors (Mediators, Proxies, Commands) are only allowed to affect change on this View Component by sending Notifications, which the Mediator hears and uses to manipulate the View Component.

There must be a coupling to attach a View Component or Data Object (local or remote) to any system. The devil is in the details of how that coupling is implemented.

The trick is to contain the coupling in such a way as to promote reusibility in those boundary objects, while allowing for easy refactoring in the future if those objects are replaced.

BTW, I’ve recently posted a draft of the best practices document on the website, which I hope will make this and other issues about implementation with the PureMVC framework clearer.

It’s a work in progress. It’ll be done when it doesn’t say ‘Draft’ on it any more :)

PureMVC.org -> Docs -> Praxis.

Thanks,
Cliff