commands are created based on an Notification, witch create a new instance of the associated command

Yes, exactly. And as puremvc insist on being the one that create the command instances, and at the same time supports no injection as part of the framework, I cannot get injection.

The singleton Controller dosent known anything about the implementation of the command

Nor would it need to.

Using a Dependency Injection pattern will make you write more code in order to make the controller inject the apropiate Proxy instance to the command

That is not true. But the framework code might become larger. A trade-off as a framework user I would like, if that made the code of the application more clear with less clutter.

Using composite in a Mediator, Proxy or Command will brake all the internal code that these classes use to register itself with the other singletons

I think you misunderstand me or maybe I haven’t been clear enough. I do not want to compose a command inside my own class, and dispatch methods to it. I would simply like to be able to create commands, mediators, proxies without being forced to inherit. With the current implementation, I am forced to.

This is a design decition. But it dosent restrain you to use platform specific API, come on! lol, what are you doing?

It should be clear, but to answer your question: “I write flex applications using puremvc”.

It is in the original blogpost above, but I feel the need to repeat myself here:

This means the framework cannot tell about what it is doing using the flash trace() method. I suspect this to be the reason that there is no debug option to turn on in puremvc. It also cannot utilize flex or flash event classes. I suspect this to be why notifications, a completely new abstraction found in puremvc, was conceived, instead of just using the event framework.

Each and every time there is a very platform specific feature, the core framework is unable to utilize it, as that part would then be impossible (or damned hard) to port to another platform.

I know it does not restrain ME from using platform specifics. It restrains ITSELF from utilizing the platform specifics.

>>Casting, Casting, Casting
The singletons in the framework let you use them as storage base for your concrete implementations of Mediator, Proxy and Command… the only way to do this is using interfaces. I think is not a big deal.

>>Forced Inheritance Everywhere
Mmh… in order to work well, the singleton Model, View, and Controller uses interfaces of IProxy, IMediator and ICommand. You extend them to implement it’s interfaces and create custom methods… this inheritance is what let you work with the framework.
Composition over inheritance is recomended ONLY if the implementation of the component’s interface is short and easy to recode. Using composite in a Mediator, Proxy or Command will brake all the internal code that these classes use to register itself with the other singletons.

>>Avoids Platform Dependencies
This is a design decition. But it dosent restrain you to use platform specific API, come on! lol, what are you doing?

>>I just think it could be done better.
Mabe if you give an example… instead of just talking… ^^

I don’t really understand this, and perhaps that is just my ignorance, but I use both bindings and event bubbling heavily in my pureMVC flex applications with great success. I’ve never once felt that I was losing anything from the Flex framework, or felt the need to say “Damn, I sure wish I could use ________ right now, but PMVC is totally restricting me”

>>isn’t that just because someone has written an ActionScript application in Python?

No, it is because outside of the API of the language the patterns in play are the same.

The portability of PureMVC is a side effect, not a stated goal. The reason the ports exist at all is because other people have found them useful, and have therefore contributed their time and effort to make them so. They are not there as an exercise in mental masturbation, stroking the ego of a framework designer.

I choose a platform because it has something that other platforms do not. If I’m creating an RIA I choose Flex, if I’m creating a animation-heavy web site I choose Flash, if I’m creating a text-heavy web site I choose PHP, Rails or some other backend technology. After having chosen the platform I choose the tools, and I want tools that let me harness the powers of the platform, that help me use the features of the platform to their limits.

PureMVC isn’t that tool ever. By design it takes away some platform-specific features — it doesn’t stop me from using them completely, just it makes them significantly less powerful (bindings and event bubbling are two examples in Flex). PureMVC is never a good fit for a platform, because it takes a least-common-denominator approach.

The other argument is that you as a programmer get more productive by using PureMVC since you can use your knowledge on other platforms. It may be true when switching from ActionScript 2 to ActionScript 3, or from either of those to Flash Lite, or other Flash-based platforms, but they are more or less identical anyway. The languages is very similar, the API:s are very similar, the runtime is similar, the execution style is similar, etc. I don’t think that it’s fair to use AS2 and AS3 as examples of changing platforms, they are too similar (but if that’s the platforms you are switching between, then good for you).

Looking at the list of platfoms that PureMVC has been ported to there are such extreme differences, PHP and ActionScript 2, for exampe, have almost nothing in common besides being programming languages. They run on platforms that have extremely different execution models, their API:s are two different worlds. Same for C# and Perl, or Ruby and ColdFusion, and so on. AS2 to AS3 I do understand, but even AS3 to Flex is questionable.

The application framework is such a tiny thing compared to the differences in language, API, execution style, runtime peculiarities, that is why I find PureMVC’s portability utterly useless.

Joel mentions that when looking at a Python PureMVC application it’s instantly clear what is going — but isn’t that just because someone has written an ActionScript application in Python? I mean, you can write Fortran in any language.

By all means, use PureMVC for AS2 and AS3 applications. I have issues with the design of the framework (besides my other reservations), but I don’t know of any better. You may even say that being able to use the same framework in both AS2 and AS3 applications is helpful to you, and I won’t disagree. But you can’t go from there to saying that PureMVC being portable to any platform is useful, or that it says something about the usefulness of the framework on that platform. I’m sure I could port Wordpress to Flex, but it would most definitely not be useful.

This is the underlying beauty and architectural strength of the framework. It is simple, generalized and easy to manipulate to your specifications. When I am writing in Flex, I extend the base patterns to conform to my needs for the application. When I am writing in AS3, I do the same. Now I have a library of useful utilities to develop with.

“for example by saying that it’s a pretty useless feature.”

It is a useless feature… to you. Coming from the perspective of somebody that writes applications in using the Flex framework, pure AS3, and Python it is nice to have a similar context across all three approaches. When I look at a PureMVC Python application it is instantly clear what is going on. I’m sure the folks using PMVC in AS2 appreciate the efforts as well.

As much as I love Flex, when I want a widget, tossing the framework overhead onto the file for no good reason is depressing (almost offensive?). The ability to use a similar framework and shared model layer without the burden of additional frameworks is very useful.

While entitled to an opinion, I think by the definition of the term useless, this particular one is incorrect.

Looking over your Mate examples, I really appreciate that effort (Mate looks like something I want to add to the toolbox). Your Cairngorm critique still has me nodding my head in agreement, but I disagree on the PureMVC hate, if for no other reason than it has been incredibly useful to me.

I shall try to completely ignore you getting personal, and instead try to extract some of your actual arguments about the post and about puremvc.

When you say:

.. So by your estimate, PureMVC should work with Flex and nothing else because you want to use Dependency Injection? ..

No. I would not dream of trying to impose that on puremvc, as that would go against the main design goal of puremvc.

…If all you’re going to do is whine and complain that something sucks, and do nothing to help, then please do sit down. You aren’t helping…

Obviously, I disagree. I actually believe I *am* helping.

Helping is the main point of this post. Not help in the sense of changing the framework. But help people choose a framework that suits them. I myself find it hard to choose a framework for a platform. It is not until you have actually worked with a framework, you discover the real pros and cons of it. I myself would have liked to read a post like this good one, before choosing puremvc. I might very well have choosen it anyway, hey, I might even choose it again.

Now, that said, both Theo and I seem to disagree with you on how much of a value-add the portability of the framework is for the user of the framework, as opposed to the value-add of having platform specific features in the framework itself.

When you write:

The fact of the matter is NO framework is perfect in everyone’s eyes.

You are actually quite right and spot on there. That is also why this is a good post. This post, together with the comments, helps possible newcomers to the flex world, to evaluate if they want to use puremvc or not.

Theo, I have no problem with you disagreeing with the way PureMVC is implemented in the Flex context however it would be more beneficial if you also proposed a solution rather than just parroting the perceived deficiency.

And yes, my comment of, “if you don’t like it don’t use it” is that simple. Or a better one would be, if you like it but find some issues with it, help make it better! If all you’re going to do is whine and complain that something sucks, and do nothing to help, then please do sit down. You aren’t helping.

Calling the feature of portability “useless” I think is very short sighted. If you don’t ever intend to switch platforms then I agree it’s probably a less desirable feature for YOU and a platform specific framework might be more desirable for YOU.

However, for myself, and others I’m sure, the ability to learn one framework and use it across multiple platforms outweighs the small benefit of using platform specific features in the framework itself. Right now I’m forced to develop in AS3 only because the Flex framework is simply too large in file size for my app. However, when the time comes that Flex is either optimized in DL size, or the entire world has the framework cached locally, I’ll most certainly port my whole project over to Flex. And when I do I’ll have very little code to rewrite AND I won’t have to learn yet-another-damn-framework.

Then there’s always things like Flash lite. What happens when my company decides they want a version of our app on mobiles? Learn another framework? How about a desktop version using AIR? Rewrite my code again? How about my back-end in another language (PHP or Java)?

That’s now 5 platforms I could use for one app and 4 frameworks I didn’t have to waste months learning and rewriting my app for. That is the power of PureMVC to me. Not whether it is the absolute best solution for each platform but rather the time savings across ALL of the platforms I can, and will, use.

Since PureMVC is touted as a Flex application framework, among other things, I think it’s fair to criticize it for being bad at it. It’s probably not as bad for pure ActionScript applications, but that’s just because it’s less limiting for those.

Since one of the fundamental ideas behind PureMVC is being portable, then I think it’s fair to criticize it on that point — for example by saying that it’s a pretty useless feature.

Since many think that PureMVC is a good application framework for Flex application development, I think it’s fair to criticize their reasons for doing that, if I can make a case for it that is on a higher level than “you are stupid”.

It’s definitely not as simple as don’t use it if you don’t like it. You can hate five parts of something while still using it because of the overall benefits. Pointing out the problems leads to progress, asking dissenting voices to shut up leads to the opposite.

By the way, Luke Bayes and Ali Mills have released a fork of PureMVC called FlexMVCS: http://www.asserttrue.com/articles/2008/07/15/flexmvcs-released It gets rid of the most annoying anti-Flex-isms, and the worst architectural issues.

Why don’t you stop complaining about how all the frameworks out there have it wrong and BUILD YOUR OWN. Save the rest of the world from your complaining how everyone else gets it wrong and you are right. I honestly can’t stand people like you. Nothing but complaints all the while you do nothing to contribute to the end goal.

If you don’t like it, don’t use it… it’s that simple. If you like it but think it could be improved, contribute! Don’t just bash it for the sake of some blog views.

I find PureMVC almost offensive in its invasiveness. I do not agree with those that think that PureMVC is a good example of object oriented programming, quite the opposite, to me it looks more procedural than anything. The focus on global variables and centralized event dispatching, are two examples of this, but the inflexible types that require you to cast all over is also a sign of bad, non-object oriented design.

And don’t get me started on the portability issue, why on earth would I want to trade the power of my platform of choice for portability? My application code is not portable, so why care if the framework is portable? I don’t choose application framework first and platform second. I choose the platform because it has the features I need to get the job done — to then choose an application framework that denies me full use of those features would be nothing short of stupid.

If you have any argument for the benefits of PureMVC’s portability, please post it here: http://stackoverflow.com/questions/143403/how-does-the-portability-of-puremvc-benefit-the-application-developer

I use Mate and my application code has zero dependencies on the framework.

How would this work for multiple instances of the same proxy class?

It would not

Or, it could be made to. I am not quite sure how deep the metadata support in AS3 goes, but if an annotation like this one:


[Inject("PROXY_NAME_HERE")]
private var clientDataProxy : ClientDataProxy;


is retained in the bytecode after compilation INCLUDING its parameter, there should be no trouble to implement injection of the same proxy type, but with different names, inside a framework.

…as for the “over casting”, well I just think (correct me if I’m wrong, I want to learn) it comes from the fact that lots of stuff in PureMVC is based on interfaces (I see it as a good practise) and quite “abstract”…

I do not agree! In the case of a retrieveProxy call on facade, it is true that the return value is IProxy–an interface. But, to utilize that value, I would either have to (a) call getData() on it and get an Object instance, which I would then have to cast, or (b) cast the IProxy instance itself, to get access to call some of the methods on it. This is what comes with using type-safety in AS3.

BUT: If the framework itself had been designed with injection instead of with some more generic service-locator mechanism, I would not have to cast. I would have the correctly typed instance available.

For example, I recently had a project that used multiple instances of a simple XML data proxy class, each created with a unique name and XML file URL. Each worked exactly the same, just loaded different data.

It looks like the method you talk about would require a single instance per class, or am I missing something? I’ll admit, DI is a relatively new concept to me.

Thanks.

I still find PureMVC much more object oriented and flexible than other frameworks, as for the “over casting”, well I just think (correct me if I’m wrong, I want to learn) it comes from the fact that lots of stuff in PureMVC is based on interfaces (I see it as a good practise) and quite “abstract”. However, personnaly, I’d say Cairngorm or Mate are much more “strict” when it comes to using them in your code … And well your previous post on Mate almost made me think I should never use it

Cheers

At a previous project I ended up refactoring all the core classes in the framework to use composition rather than inheritance. The fact that Mediator subclasses Notifier is unnecessary, and makes testing difficult.

We also made a blanket rule that facade.retrieveX() was forbidden in any code except Commands, to avoid tightly coupling objects together. (At the time, we weren’t able to use a DI framework, which would’ve been preferable as you mention).

We found that using the facade.retrieveX method creates dependencies similar to being dependent on a singleton — the amount of setup code for a unit test becomes very heavy very quickly.

Great post!

Marty