Over the holiday’s, I went to PureMVC.org to read over the documentation. PureMVC, although a year old, is the new framework on the block for developing Rich Internet Applications atop the Flash Player. There are plans to port the framework to other languages and runtimes like PHP & Silverlight in the future. Like Cairngorm, it’s a framework that uses coding conventions based on design patterns, namely the meta pattern, Model View Controller written in ActionScript 3. Unlike Cairngorm, however, it has no ties to the Flex SDK. This means you can use it with Flash CS3, Flex, or just pure ActionScript 3 projects.
If you are a computer scientist, you’ll love the documentation. It’s chock full of design pattern discussions, justifications on framework implementations, and visual diagrams all in a nicely organized website. If you’re like me, the docs will get old after 30 seconds. I went straight to the example Flex project you can download to learn how it works.
Upon digging, I found some familiar coding styles, and some unfamiliar. When I saw the use of View Mediators, however, I immediately got a bad taste in my mouth. I composed myself, and sent off a non-leading email off to Joe Berkovitz asking his opinion. I’m still waiting to hear back from Thomas B. I won’t speak for their replies, but it’s nice to know that not everyone finds PureMVC uber-perfect as the blogsphere’s reaction this past year has suggested.
My first gripe is with View Mediator’s. A View is form, GUI, or some other visual control; it’s what the user sees in MVC. View’s can read from the Model, and ask the Controller to do things, inform the Controller of user events, and be informed by the Controller of the Model changing. A Mediator is a class that allows various classes to talk to each other without tight coupling. It is the de-facto design pattern in developing Flash & Flex applications. Farata Systems has a great post talking about it in context. A Flash Developer explanation is, “It’s a MovieClip that holds other MovieClip’s and allows them to talk to each other without them ‘knowing’ about each other”.
In PureMVC, a View Mediator is created for each View. You don’t need to create this for all View’s since some via Composition (View’s used inside of other View’s) aren’t all that complicated and thus you don’t need to create all this code for such a simple class. The purpose of the Mediator as I’ve seen it used in the example Arch101Demo is to respond to Application state changes and/or events in the form of Notifications. Secondly, it can interact with Proxies to data; basically liaison’s to the data.
There are a few problems I have with the first part. The Notifications contents are not strongly typed and thus suffer from the same problem that Cairngorm’s Delegates do that implement mx.rpc.IResponder. In Cairngorm, your Commands (classes that do Controller logic) can implement an interface called IResponder. This allows them to work with Delegate’s, classes that make web service calls. They return either a result or a fault. While the onFault is great in that you get back a FaultEvent that contains detailed failure information, ResultEvent is useless. You have to make assumptions on the data you get back since ResultEvent.result is cast as an Object. If I ask the server to give me a Person object matching an specific ID, I should get that back in my result event. If not, something went wrong, and my fault should be called. Instead, you have to force the Command (assuming you follow the standard Cairngorm Command way of implementing the IResponder interface) to “parse” data. Parsing data should not be in the realm of Controller logic, and instead be done strictly by services. Notification’s getBody, and other functions suffer from this same problem.
It’s not the end of the world; people cast flash.display.Loader.content to what they “think” they are loading all the time. However, PureMVC had the opportunity to get things right here and they didn’t. The INotification interface’s list of functions (excluding getName) should at the very least return a type interface instead of Object. If you’re going to follow the whole “programming by contract” methodology, do it across the board and not just where you feel like it to support your framework.
The other gripe is with ApplicationFacade events. You define Notification types (like Event types) that your Application will dispatch as constants. Your Mediator’s can then listen for these specific Notifications and react to them. This allows multiple Medator’s to listen to a single Notification. Whether they re-created their own event system instead of using Flash Player’s built in EventDispatcher system with custom Event classes for framework reasons, or whether they were trying to prevent application developers from burning themselves with un-registered Notification listeners causing memory leaks isn’t my main frustration. What is bad is that I fail to see how putting all of these events on ApplicationFacade will allow your application to scale in size.
The whole reason you extend the AS3 Event class is to provide context to those who respond to those events. Some don’t care about context; for example, Application startup. However, when clicking on a List control, you need to know what item was selected, what was the previous item if any, what is the index of that item, and for View’s a strongly typed reference in case the Event bubbled up to you from a deeply nested View and you have no way to access the List in a parent child way. You can’t do that if you have a bunch of event names in the form of Notifications. Granted, you could package the payload into the Notification itself so it can act like an event, but the Notification has no strongly-typed way of doing that based on the INotification interface, and suddenly your packing in information into a Notification that others may not need. Granted part deux, yes, you could create your own Notification class, but explain to me why we’re not extending the built in Event class again? Event’s can bubble and be intercepted.
Mediator’s have a reference to the View instance they are representing. The problem is, it’s up to the developer to handle this marriage. Cairngorm had something similar called a ViewHelper. It’s now deprecated, but the point of a ViewHelper was two-fold. First, it did the same thing Mediator’s in PureMVC try to do; greatly simplify the amount of logic in View’s. Second, they provide a non-GUI based class that can interact with others, preventing the View to have to know too much about the framework it’s in. In Cairngorm, they had an extra bonus of working well with a ViewLocator; a globally accessible class that allowed anyone to access a View’s ViewHelper by a magic string; it flattened the tree of GUI View’s.
Mediator’s in PureMVC are definitely successful in those goals. If you look at their code and what the View’s in the example app are doing, it’s certainly more readable. There are also a lot less dependencies than say, Cairngorm where the second a View dispatches an event via CairngormEventDispatcher, it “knows” about Cairngorm.
However, the down-side was in Cairngorm, ViewHelpers were created by the View’s. There was a 1 to 1 relationship that was instantiated when the GUI View was created. You couldn’t really screw that up. Although it was opt-in, a lot of people new to Flex just created 1 ViewHelper for every View. In PureMVC, they suggest you not only instantiate a Mediator yourself in a Command, but you also hand it the View instance yourself. While not major since ActionScript 3 allows us some strong-typing to ensure we “have the View we think we have”, why in the hell is not done for you? It’s an area where a developer can mess up; either they forget to actually create their Mediator, or pass in the wrong View reference. This is minor, but the whole point of a framework is to help you write less code, not more.
Worse, what if I have multiple View’s? Do I then have to have each dispatch a new Notification (onUserEditViewCreate) just so I can create a new Mediator with a new View instance reference in a Command? WTF… the framework should handle these low-level details.
The biggest gripe I have with PureMVC, and the one that made me all negative was how Mediator’s have access to Model Proxies. The ONLY person in MVC who should be able to SET data on the Model is the Controller. A Mediator, although merely having a reference to a View, IS associated with a View. It should NOT be setting data on the Model; the Commands should be doing this by listening to events (Notifications, whatever) dispatched from the Mediator’s. Just because a Command creates them doesn’t suddenly bequeath them Controller ‘esque powers. This is probably done this way because of my last gripe…
…PureMVC Commands do not follow a true Controller pattern of setting data. One is instantiating a Mediator (StartupCommand) while the other is updating the Model (DeleteUserCommand). What the hell? I’d argue the DeleteUserCommand is correct, and the StartupCommand is wrong. In fairness, that’s because I’m comparing them to Cairngorm Commands. I’ll admit, this is the weakest argument I have, yet you have to agree it’s not consistent on what Commands are really for based on the example. Updating data? Creating things to have them update data? What if the Command wants to intercept the Notification and do something first, preventing the Mediator from doing it? Without a core Controller, you now have multiple types of classes setting data on Proxies. I can see it now… “Did I set the data in the Command or the Mediators…? Man, this’ll be a long morning…”.
Thoughts on Code Behind
On a side note, this is the second time I’ve seen a framework cater to a View code behind model. The theory and practice of code behind as it relates to Flex has been talked about and lauded a lot so I’ll leave it to Google to give you more details. The idea is that you utilize 2 classes or files; 1 for GUI and 1 for logic. The reasoning behind it is “separation of concerns”, the traditional computer science idea of making a large program easier to manage by breaking it up into pieces that each manage their area of interest. A lot of code in complicated View’s has absolutely nothing with drawing visual graphics to the screen, and is merely the logic behind the View. The current reason I don’t support this methodology in Flex is that FlexBuilder does not support it well.
Silverlight & WPF on the other hand have tools built around this idea. In Blend, you control the actual real guts of the View; it’s layout, visual look, and transitions via XAML (like MXML). In Visual Studio, you code the logic behind it in C# or VB (like AS). In Flex, this currently feels forced. While convention helps, you don’t really get any help from the IDE in doing this methodology. This doesn’t bother me as I like coding my View’s to be 1 file and encapsulated. This can reduce readability, however, for complicated View’s that have a lot of code that doesn’t really relate directly to how the View displays itself.
Cairngorm was the first framework I saw advocate this methodology via the aforementioned ViewHelper, leading me to believe that this is something Enterprise Java devs are used to doing. PureMVC is the second with the added twist of using the code behind not just as a separation of concerns, but also as a mediator the rest of the program that the View interacts with, hence the appropriate name. I typically use Mediator’s via Composition like Farata Systems linked above describes it. It is definitely a creative way of handling SoC and code behind in a framework way.
Maybe if Thermo could create well written MXML and Flex 4 well written generated code-behind, I’d dig the idea and actually use it on projects.
Code-behind is definitely a Java/.NET thing, which means by extension it’s a web application deveopment thing. The legions of non-Flash people who are coming into Flex are going to be doing code-behind, and where Adobe’s tools don’t support it they’re going to come up with their own way of doing it.
I started programming using PHP, where it’s very common to throw pages together as a variegated havoc of HTML tag soup and barely-even-procedural PHP code sprayed wildly into a file that resembles an e.e. cummings version of Beowulf more than a working program. That kind of thing becomes unmanageable very rapidly, and separating the more repetitive blobs into their own files for inclusion only helps a bit.
I was excited by Flex, after years of having to punch Actionscript in the dick to make it do things Java did as a matter of course. Then all these tutorials and even professional books started coming out with example code that looked no better than the slapdash PHP I came up with. With Flex code-behind, I was able to restore order. I betcha the most sought-after Flex coders right now — the guys with extensive enterprise Java and .NET experience — are feeling the same way. No clue if FlexBuilder (and Flex itself) are going to start seeing increased support for code-behind, but I wouldn’t be shocked at all if that’s the way major shops start going.
Note that I haven’t really said anything about whether code-behind is necessary or even beneficial; I’m just saying a lot of tastemakers WANT it, and that could be all that matters.
dude, apostrophe = possessive. no apostrophe = plural.
“View’s” means “belonging to the View”.
“Views” means “more than one View”.
Sorry. just bugged me enough to say something.
Jesse — for a good and reasoned overview of Code Behind, Paul Williams of Adobe Consulting has a great blog post here (http://weblogs.macromedia.com/paulw/archives/2007/11/presentation_pa_5.cfm#more) that is one of a series of blog posts on presentation tier patterns. Highly recommended reading….
Jesse said: “the whole point of a framework is to help you write less code, not more”
You sure? In the past you’ve made reference to the feeling you get when you first break into Cairngorm and discover that you have to create 4 classes to do what you used to sloppily (but with less code) put into one file. Anyway, that’s a minor point. Mostly I’m just glad to hear I’m not the only one with these same gripes.
“Maybe if Thermo could create well written MXML and Flex 4 well written generated code-behind, I’d dig the idea and actually use it on projects.”
-When I first saw Thermo demoed at Max this year, I had a similar thought… In reality, if Thermo isn’t generating code in this sort of fashion, or at least have the configurability to allow you to, it’s going be tough for it to gain acceptance in large team settings, where a designer is expected to hand-off completed interactions, UI designs, etc to a team of Flex developers. If the code isn’t solid, well documented and using common design patterns like MVC, it doesn’t make much sense to use it in a team situation. (I see flashes of Dreamweaver MM JavaScript in my memories just thinking about the bad side of standalone nonstandard autogenerated code) Ideally, if it could use preexisting frameworks like Cairngorn or PureMVC that might be even better as it would show strong support for industry trends and best practices on Adobe’s part.
Jesse,
The reason Event isn’t extended is that it belongs to Flash, not AS3.
A core goal was to remain independent of Flash or Flex in order to work with Tamarin when it gets here.
Even if Event were native to AS3, it would’ve been a hamstring to use it, since other languages may not have it or implement completely different.
The result of that one decision has been that the framework not only works in AS3 but now AS2, CF C#, Java, and PHP. Others are just a matter of time.
As for the role of Mediators, they allow you to write portable view components that need not know anything about the framework to which they are adapted. The are not meant as ‘code behind’ classes.
And Notification body strong typing inside the framework is to type Object. As with Events, merely subclass Notifiacation to add your type. Think about it for a second: how am I supposed to know what you want to pass? That’s an implementation time decision. At least over Event, I let you pass something without subclassing. So be as srtict as you wanna be.yo.
You point out that you put down the documentation and rolled up your sleeves with a demo after about 5 minutes. Then you started firing off confirmation bias driven emails and wrote a big post about your frustrations with PureMVC.
I wonder have you written an app with it yet?
-=Cliff>
Jesse,
Surely your removal of my previous reply was accidental since it merely addressed your issues. I’ll take the time to post again, since your blog is prominent and people could easily be confused by some of the issues you raise.
First, the Event class is flash.events.Event. Clearly not an AS3 native class. To extend it would be to tie PureMVC to the Flash framework, and hamper its portability to other languages.
Secondly, Mediators are not for ‘code-behind’. They allow you to write view components that are free of any ties to the framework itself, and are therefore reusable, even outside the context of the PureMVC framework. This makes porting to and from PureMVC easy.
And finally, you mention:
The biggest gripe I have with PureMVC, and the one that made me all negative was how Mediator’s have access to Model Proxies. The ONLY person in MVC who should be able to SET data on the Model is the Controller.
I would suggest taking a quick look at the simple diagram illustrating the basic collaborations of the MVC pattern found here: http://en.wikipedia.org/wiki/Model-view-controller
-=Cliff>
Jesse, is this assessment based solely on a review of the Arch101 demo or have you made some actual projects with it? You didn’t mention.
Firstly, you can’t just dismiss the effort that went into creating the documentation for PureMVC. It is well-done and far more detailed than other open-source projects. And frankly many of your arguments are covered off in it. It is worth more than a cursory 30 second glance.
Others:
– You do not make a mediator for each view, there is only ONE view. The mediator provides access to parts of it.
– Lack of strong typing on the getBody of Notifications, in actual practice, has never been a problem. As you say, it is not the end of the world, and the fact is it greatly simplifies moving data
– PureMVC is not intended for just AS3. A separate notification system allows it to be ported to AS2 and other languages as well. I like the idea of being able to work in a familliar environment across multiple languages.
– The notification system does not replace the event system, but works along with it
– Yes, mediators have access to proxies and can directly interact with them…should you so choose. I admit this made me nervous as well, so I talked to Clif Hal, the creator of PureMVC about it. Cautiously, I tried a few examples of view-model interaction, and nothing blew up. Moreover, some things became a good deal simpler. Of course, you do not have to do so, you are perfectly capable of routing all interaction through a logic command should you prefer the strictest interpretation of MVC.
It is not the responsibility of a framework to make someone a good coder. You can find a way of breaking any framework, no matter how it is made.
The good thing with PureMVC is that you can get up and running quickly. You can use it with or without Flex. It provides structure and predictability to your projects. It doesn’t try to do too much. You can employ it across multiple languages. And if you run into problems there is actually documentation to consult.
Try it out on some actual projects. It’s the only way to form a meaningful opinion. I bet you end up liking it.
-t.
@Jed: Good catch. I’ve tried doing code gen for Cairngorm, but it just never worked out very well. I’d end up hand coding stuff for minor changes thus preventing future code gen for specific use cases. What I really mean is it seems to me these common details should be handled under the covers by the framework if they are a common thing developers should do.
@Cliff: Thanks for taking your time to comment. Totally understand your reason for not extending Event for Notifications; makes sense and I agree now why you did it.
No Cliff, I’m have not written an app with it yet. I spent 2 hours reading and going through sample code, and reading blog entries about it. I’m still evaluating if it’s worth the effort, and what projects I have upcoming would be a good project to try it out. You can’t judge a framework unless you’ve actually used it. I’ve learned a ton about Cairngorm and gotten a lot of appreciation of it’s facets over the years by using it. I’m sure if I spend another 3 years using PureMVC, I’ll come to appreciate and dislike aspects of PureMVC as well. This is just day 2 of 1095.
I did look at the diagram, but I didn’t see it saying it was ok for the View to set data, only visually represent it. Read-only access for Views to the Model is fine; they just aren’t supposed to write. Granted, I’ve broken this rule on some projects in rare cases where the process of going through a lot of formal code just to set some data was ridiculous.
Regarding your comment, I didn’t delete it; I didn’t get to moderation of all the blog comments till late this morning. However, now that you have been approved, you’ll never have to be moderated again; sorry for the hassle.
@Timbot: Nope, still evaluating the framework as well as which future project I can use it on.
It may have seemed sarcastic, but it wasn’t. The docs ARE damn impressive. You can tell a ton of work, thought, and checking went into them. If you can’t use PureMVC successfully, you apparently can’t read. I’m just not a documentation kind of guy; I use documentation for later reference for minute points, not to learn things. So I’d end up using them later whilst deep on a project vs. how do I use PureMVC. I’d rather learn by doing using example code.
Point taken about the glancing over. When I get more time, I’ll do a second dive.
Regarding the Notification, I understand that, but I didn’t pay $700 for FlexBuilder not to use strong-typing. In practice, I’d extend Notification, and make strongly typed references.
Agree about multiple languages. Cliff brought up that point. Being able to use the same framework in the browser via Tamarin would be pretty dope. Although, there is that one problem with HTML… *ahem*
Notification system does replace Events but works along with it? Um… no, cop out. Again, Cliff has a very valid reason for not using Event, but choosing not to leverage the Flash Player’s strength seems like a bad decision to me.
If you’ll recall… hell, search my site, I’ve got 15 billion blog posts tearing apart Cairngorm on this blog throughout the years, yet I still love it and use it. I’m sure if I took your advice and used it on a project, I’d learn to like it as well, just waiting for the right project to come along. My side projects at home are just too small in scope.
Jesse,
No problem, I see the delay now in your moderation system. My first post was by Blackberry and I didn’t see it labeled ‘waiting for moderation’.
To your later concerns about Events, what Timbot said was:
>>The notification system *does not* replace the event system, but works along with it.
Examine the demos and the docs and you’ll see that Events are most certainly leveraged in nearly every View Component as a way of communicating with the Mediator. You are correct, it would be insane to try and replace them. When in Rome, do as the Romans do, right? But it is a matter of idiom. In a language without events, another collaboration arrangement must be arrived at.
In a Flex, Flash or AIR application, Mediators can add listeners to their view components, and the view components in turn ‘expose an API’ to the Mediator including the events, properties and methods intended to be accessed by that Mediator.
Notifications are simply used to pass information around within the PureMVC apparatus. For the aforementioned portability concerns, that had to be part of the framework. The nice thing about Notifications are that they are implemented as a Publish/Subscribe type mechanism. Disparate parts of the system (with no reference to an object to place an event listener on it) can be notified by having previously registered an interest in the given Notification.
-=Cliff>
Cliff said, “First, the Event class is flash.events.Event. Clearly not an AS3 native class.”
A tiny clarification I’d make is that flash.events.Event is not native to ECMAScript. The flash.* package is definitely a native part of AS3 in my eyes.
I completely agree with Cliff in that I don’t think you can compare Mediators with “code behind”. I don’t see them as the same thing at all. I’ve also discussed this framework with Joe Berkovitz, as I work with him, and I think before you use him as backup for your argument you should at least share his view or at least acknowledge that he has little to no first hand experience with this framework. That is unless he spent the holidays playing around with it. I’ll be sure to ask him his opinions when I get back to work this week.
How is it not like code behind? It gets a reference to the View its representing and starts calling methods on it to mediate data changes and reactions to those changes.
You wouldn’t want me to blog emails you thought were sent in confidence. Besides, he has his own blog where he can express his views. Unlike me, however, he’d probably spend more than 2 hours taking a sampling and making first impression comments.
I don’t feel like the framework is advocating putting all of the view logic into a separate class, this is why I don’t see it as code behind. From the documentation:
“A Mediator connects a View Component with its data and communicates with the rest of the system on its behalf.”
I got the impression that the purpose was to insulate the view component from the overall architecture and didn’t see anything against creating a complex view component which had its own internal logic and functionality contained within itself. Maybe the code examples you looked at were simple enough where it just so happened that all of the “guts” of the view were contained in a Mediator class, but again I don’t think code behind, in the meaning that we tend to argue about it online, is being advocated here. Cliff can correct me if I’m wrong.
Josh wrote:
>>A tiny clarification I’d make is that flash.events.Event is not native to ECMAScript. The flash.* package is definitely a native part of AS3 in my eyes.
It isn’t a sentimental thing, or something where it’s ok to have differing viewpoints. flash.events.Event is NOT a top level class.
Here are the top level classes as defined by Adobe:
http://livedocs.adobe.com/flex/2/langref/package-detail.html
And a nice cheat sheet for your wall:
http://www.actionscriptcheatsheet.com/jpg/as3cs_toplevel.jpg
AS3 is an implementation of the late model ECMAScript standard, and it happens to be used inside Flash. Flash, is a framework for creating things that move around and interact using an event driven model, so the Flash framework has a package called flash.events.* for dealing with that.
Adobe is open sourcing the AS3 engine, (called the AVM2) and is working actively with Mozilla to embed it into the next version of Spidermonkey. The project is called Tamarin, and it is highly unlikely that its event class will be flash.events.Event or even work the same way.
This was common knowledge at the time I started with PureMVC, and so it seemed foolish to depend on Flash framework packages would preclude or at least seriously hamper the portability of PureMVC to Tamarin in the future. That’s the next version of JavaScript! Finally AJAX in the browser may make sense! But those people will need a framework.
-=Cliff>
I’m too much of a design pattern noob to add anything substantial to this discussing. But let me say this: having worked with PureMVC on a few projects I cannot recommend it enough. I am the type of coder who needs to use all the help he can get, I want to be forced into a best practices approach because I can’t implement them myself yet I knew I needed to stop writing Controller classes that were growing out of all proportions – I knew I was doing things wrong but couldn’t fix them myself. PureMVC did the fixing for me and I no longer need to feel ashamed about showing people my code.
I am in the same boat as Stefan and share much the same opinion as him. Although my previous Flex projects were functional when it came to scaling and team project work they would have proved arduous. PureMVC structured Flex and Flash projects created a logical architecture which has enhanced my applications 10 fold.
Cliff,
I’m not being “sentimental” here. Just because classes are organized into nice packages doesn’t mean they aren’t part of the language. I guess our argument hinges on whether ActionScript == ECMAScript. In my mind, ActionScript and ECMAScript are different. ActionScript is a superset of ECMAScript. It includes a lot more native classes (which were nicely organized by Adobe into the flash.* package). Tamarin implements the features of ECMAScript, and it obviously won’t include flash.events.Event, because that’s not a part of ECMAScript.
By the way, I think that it’s cool that you’ve built a framework that will work across many different ECMAScript implementations. PureMVC is a very cool project in that regard.
Alan Says:
“I started programming using PHP, where it’s very common to throw pages together as a variegated havoc of HTML tag soup and barely-even-procedural PHP code sprayed wildly into a file that resembles an e.e. cummings version of Beowulf”
Quote of the day.
Cliff says:
“the Event class is flash.events.Event. Clearly not an AS3 native class”
Josh says:
“The flash.* package is definitely a native part of AS3”
I understand the confusion around this, and it is certainly not “clear”.
To quote Adobe:
“The Flash Player API is a set of classes and functions that expose the capabilities of Flash Player to the ActionScript language. This functionality is the bridge between the ActionScript core language and the rest of the platform.”
That is what Cliff is talking about, “the ActionScript core language”. Usually though, Adobe’s general wording implies that the Flash Player API is a part of AS3. Both can be considered native.
In the end, this is nothing AS3 developers in general need to care about, Event is there, either you program in Flex, Flash, or pure AS3.
hi Cliff,
How to access webservice using PureMVC .Plz help Me!
Got to say Jesse…
Normally you are bang on the money, but this time you are really mis (self) informed. The sad thing is that many people will have read this post and made a mental note that PureMVC is not worth their time. A decision based on your mistaken understanding of a really excellent framework.
Will definately take everything you post with a very healthy dose of skepticism from now on.
This post is a record of my initial reactions in reading through the initial sample code PureMVC provides. It is not a summarization of PureMVC’s capabilities in total, nor a final statement to the world on my final stance on PureMVC. As I stated, I’ve made dozens of posts similar to those on Cairngorm picking it apart in order to expose it’s strengths and weaknesses, stimulate conversation in the community about these issues, all in the pursuit of learning.
Furthermore, my readership is capable of thinking for themselves.
In the interest of furthering those pursuits, why not point out what I’ve gotten wrong above vs. stating that I’m just blatantly wrong across the board, because I’m not wrong on a lot of what I’ve said. I still stand by everything I’ve said above including things in the comments where I’ve changed my stance on some issues.
Nice post. Some of it in line with our own experience. I don’t understand comments like “Normally you are bang on the money, but this time you are really mis (self) informed. The sad thing is that many people will have read this post and made a mental note that PureMVC is not worth their time”. Like Jesse said, it’s just one man’s opinion, people can decide for themselves. I’m sure PureMVC will work wonders for some.
We looked at PureMVC a few months ago, and there is a different side to everything. For example some say “It’s very well documented”, while other say “Damn if it needs this much documentation…”. I posted on some of this a couple of months ago, surprised that all we heard about PureMVC was positive (which isn’t to say we thought it was all negative mind you, it’s very easy to get personal on this kind of stuff:)). Some of our experiences can be found here http://objectpainters.com/blog/2007/10/20/flash-frameworks-revisited/
In general we looked at both the documentation and a few examples. The CafeTownsend example in particular, assuming that since it’s posted on the PureMVC site, it is considered well written. But it’s not however, and I think putting examples out there that contain a number of bad practices is not good promotion for a framework. I’ll try to find some time to blog about what I think is good & bad about that example in particular soon to pour some more oil on the discussion :).
Note that if you read the aforementioned post, you’ll come across “I’ll dive into what itches in the PureMVC examples in my next post. I’ll ask Cliff for his feedback on those points as well, since there is ofcourse still the rather large possibility that we’re simply missing something.” Erm yeah, still working on that one…
I started with ARP. Then migrated to Cairngorm. And now I’m a PureMVC addict. Especially the multicore version. It’s the best framework to use when you have a team working with you, It’s the less intrusive framework from all three, and it’s the cleanest one – it’s easy to move different components and parts to other projects since there aren’t dependencies on your code.
Of course, it’s not perfect – I don’t feel very comfortable in the way how proxies work with delegates.
My next step is to learn Pipes for PureMVC for inter-module communication.
All above three frameworks are great, but the cleanest one is PureMVC for sure.
If you are looking for an MVC framework to write less code, you are looking the wrong way… and also, who said it was good to write “less code” ?
What we currently need is a good code generator (the ones out there suck), especially one that allows you to draw UML….