Cairngorm "best practices" are fuzzy at best and non-existent at worst. I tended to use this architecture when using that bloated framework:
I suspect IModelLocator may come from a different (newer) version of the architecture. Since I've sworn off the use of such a boilerplate demanding monstrosity, I can't say whether it is newer or not. If you really want to adhere to the most defensible "correct" approach (there is none really), I'd suggest you do what the latest official Cairngorm examples do. If there's inconsistency even there, then really you'd have to ask the maintainers of the architecture what gives.
If anything I've been moving away from more structured 'frameworks' more and more over time. Swiz is one of my favorite since it's so lightweight and flexible (definitely different from Cairngorm), but for some Flex apps even that may not be needed.
I am newbie to Cairngorm ...
See , you've messed up already ....
Save yourself some pain , learn a seccond generation framework ( Mate , Swiz ) not Cairngorm and certainly not PureMVC.
The trend is toward inversion of control (IoC aka Dependency Injection) frameworks for Flex.
Adobe Consulting has created Cairngorm 3 libraries on top of Parsley
IoC FTW. I hadn't heard of Spring Actionscript. Looking over the documentation , it looks pretty simple. But it also seems like it has some of the same annoyances of Cairngorm , PureMVC. That being that they are descended from the Java world , which is HUGE ( JPL,J2EE,Java Imaging,JDBC ) compared to the AS3/Flex world. Sometimes, it seems like this leads to such an abstraction, you end up with a mountain of boilerplate code to get anything simple done , IMHO.
For simple applications, architectural frameworks are not required. They uselessly complexify everything.
For more complex, data-driven applications, especially in the enterprise, you have to use one or you risk creating your own boilerplate code to cope with complexity...
The Java world and the Flex world are intermixed. LCDS and Blaze DS are implemented with Java and run on Java Application Servers, just like other Adobe LiveCycle products. Go to Java One to get a feel of it.
I concur with the sentiment above hinting that Cairngorm is mostly a has-been architecture largely due to requiring too much boilerplate code. I will add, think carefully before drinking the Mate kool-aid (possibly the Spring Flex framework?), as even the Java world is starting to realize the insanity of XML configuration ("XML programming" if you're a critic) schemes and has been moving away from this.
In fact take anything, other than IoC/dependency injection (the true reason for Spring's early success IMO), related to Spring with a grain of salt since the name recognition inspires so many bandwagon jumpers attempting to capitalize on Spring's early success with IoC. Just because it has the 'Spring' stamp of approval on it doesn't automatically make it a good idea or a good design.
So what architecture type/frameworks do you like ? I have seen Google Guice online line and even toyed with it. I have yet to build an application that runs with it though.
Anyway as for Guice, I *think* I had good impressions when I briefly looked at it, but I've yet to use it or even look into it in very much depth. It doesn't seem to be "taking off" in any big way yet, unfortunately. Unlike many I do not give supposed "industry standards" (such as Spring) the benefit of the doubt, and having seen Spring evolve over the years, I am looking to move on to greener and more productive pastures while taking the core lessons learned (IoC, TDD).
So currently I generally use Spring in Java, Swiz (or nothing) in Flex.
Spring is still heavily used in the Java community.
There are some new Java projects that use it in the enterprise.
As everything, it has been created to solve some problems. Then, as you use something, you see its shortcomings and move on to something else.
As everything, it has been created to solve some problems.
And created some new ones in the process. (Too many people assume "the Spring way" == "the best way".) I do wonder why Spring has such an XML fetish - didn't their mommas teach them that compile-time errors are greatly preferable to run-time errors?
How would you get a run-time error with XML injection but not a compile time , you can see what classes/interfaces you are injection , no ? And we must remember how the framework jungle looks in Flex/AS3 as of today. When you take into account trying to structure an app with things like Cairngorm and PureMVC , the cure is worse than the disease. I would take (m)xml over those two any day.
But I saw something on a blog which really summed it up , "No architectural framework can make a bad programmer write good code". I've seen people use frameworks as a crutch , when I mentioned the lack of separation of concern to a former co-worker , his response was "but we're using PureMVC !" It all boils down to the basics and people learning "best practices" of the language and programming in general , regardless of the framework. It just turns out that some frameworks start out as the inverse of best practices.
</Rant against garbage programmers>
How would you get a run-time error with XML injection but not a compile time ,
A simple text typo (or even screwed up xml tag), entirely forgotten bean, refactored class name (if you do a quick refactor), wrong class type, forgotten injection (although admittedly this wouldn't be solved by dumping xml config), produce those annoying run time errors. Especially annoying in web dev since you have to deploy your entire app to a slow, bloated web container before you find out about any run time errors (and even then, it's only one at a time, if you have 5 errors we're talking 5 deploys to fix them all--ugh!). Setting up Spring Security is especially painful thanks to XML shenanigans. And don't even get me started with dependencies and "jar hell"... (more run time errors).
The naive may make claims like "you're using the compiler as a crutch!", but I call bull on that--why throw away a useful tool that can instantly point out problems for you?
Also when I say "XML" don't take that as a rant against "MXML"-- actually I think mxml is fantastic. A very simple and ingenious solution, which actually *reduces* the amount of code we write. MXML does produce compile-time errors, so it's a win-win. Not so with a Spring (or any) XML "application context" or config file. Now I'm not completely against them (some mild usage, especially like BlazeDS or GraniteDS does, doesn't hurt much), but when we're actually replacing a ton of source code with "XML programming", alarm bells go off. I'm sure some Spring apologist will claim TDD "fixes" their run time error deficiency but, meh--not really (sounds like a real crutch to me ).
Like I probably said above I think I'm with you on moving away from frameworks, or at least using non-intrusive, lightweight, low-configuration frameworks that don't impose knee-jerk patterns on you. Swiz being the example I have in mind (although honestly I'm not sure how well it scales up for very large apps).
I've not used it yet, but here's an example of what I'll probably look into as an alternative to "standard" Spring (w/xml). A "pure Java" way of doing Spring DI. Still "Spring" in name, but not all "Spring products" are equal--some are good, some are for the kool aid drinkers IMO.
How to get SWIZ RC1 running with Flash Bulder 4 ?
As far as I add the swc I get those warnings and the project will not be runnable nor can I see something in the design view:
Description Resource Path Location Type
Design mode could not load swiz-framework-1.0.0-RC1.swc. It may be incompatible with this SDK, or invalid. (DesignAssetLoader.CompleteTimeout)
I even tried if this might be fixed in Flex SDK 4.1 but its the same.
Any Idea how to fix ?