Quite interested on

“Furthermore, we wrote our own framework on top of PureMVC to allow more ‘graceful’ handling of notifications (instead of switch statements) and to provide other convenient features such as centralized configuration (based on conventions) in an mxml file, logging service, etc.”

I am facing same problem. And planning to use “naming convention” to load the processor which maybe controlled by IoC.

Same question as
” polesen Says:

@Alain:

Interesting. Are these extensions to puremvc something you have published (or are considering to publish) in some useable, possible open and free , form?

If not anything else, then maybe just the ideas and examples, for others to follow or simply learn from?
“

The problem is that they must have agreement from the management knowing that corporate communication is rather controlled.

Nevertheless, I can still push to see if it’s possible to release it under one form or another.
In this case, I’ll let you know.

Interesting. Are these extensions to puremvc something you have published (or are considering to publish) in some useable, possible open and free , form?

If not anything else, then maybe just the ideas and examples, for others to follow or simply learn from?

Furthermore, we wrote our own framework on top of PureMVC to allow more ‘graceful’ handling of notifications (instead of switch statements) and to provide other convenient features such as centralized configuration (based on conventions) in an mxml file, logging service, etc.

The framework is not perfect and the learning curve is quite long for new developers but the result in terms of application design is well worth it, imho.

The one big problem I find with Cairngorm is its core singletons – i.e CairngormEventDispatcher and the evil evil real singleton -ServiceLocator.
These can give you some really hard time building modular application.
I found arc90 Modular kit, which solves some of this problems by using the CairngormEventDispatcher as Multiton.

Also, I really recommend reading Jesse Warden 10 tips for using Cairngorm:
http://jessewarden.com/2007/08/10-tips-for-working-with-cairngorm.html
he’s got some very good points there.

While PureMVC has a longer learning curve (took us approx an entire half day to work our way through an intermediate example), I feel it has a lot more to offer especially for those not used to using the MVC architecture.

It seems a shame that most larger companies are going with Cairngorm by default since it has been endorsed by Adobe and not even considering alternatives like PureMVC.

I second what Per says, the publicly available information about best practices in Cairngorm is really bad. When evaluating application frameworks for Flex there isn’t much else you can do than read the documentation and the example applications, and here Cairngorm fails miserably.

- The documentation is more or less nonexistent, the cairngormdocs.org page (which one must assume is the closest thing to an official hub for Cairngorm information) lists your tutorial written for Flex 1.5 as the first and only tutorial. The rest is just API references, which is utterly unhelpful if you’re not already using the framework. The “community” is a mailing list where most of the messages seem to have the subject “Help me”, and scanning the headlines of the blog gives me the impression that most of the content there is for those who already use the framework.

- Then there’s the example applications, and it’s good that we now know that they aren’t worth looking at if we want to know how to really understand Cairngorm. The problem is that there doesn’t seem to be any alternatives. What comes after “advanced” if “advanced” means “simple”?

On these points PureMVC fares much better, and factoring in architecture too there should be no doubt that if the choice is between Cairngorm and PureMVC, PureMVC wins hands down tied behind its back and blindfolded. That being said, PureMVC has it’s fair share of problems.

When you say:

CairngormStore is intended as a very simple example of using Cairngorm, it’s not the approach advocated for all applications. Cairngorm isn’t prescriptive about the view, it simply recommends that you leverage data-binding to bind data between model and view…

I could say “ooh, okay”, but in my opinion, documentatation and examples therein are key to a framework, as they communicate the intent of the framework and the parts of it. One part being the view, of course.

The Cairngorm Store application on cairngormdocs.org is listed as the “Advanced” example. You mention it as a “very simple example”. There is a discrepancy here.

Maybe what Cairngorm needs is better documentation? For instance, if what you say is the intent of Cairngorm, that it isn’t prescriptive of the view, this should be clearly documented, including why and what the implications of this is.

In short, Cairngorm needs a “Best Practices and Implementation Idioms” document, at least. People looking into using Cairngorm is looking for architectural advice. They will grab the examples, and do what they “say”. After all, what else should they do?

I have read the posts of Paul Williams, and I think they are great. Indeed I link to them under “Further Reading” above. Even though their intent was to show how to unittest the view, they can be used to solve this problem with Cairngorm too.

Please see Paul Williams blog for excellent descriptions of many of Fowler’s patterns implemented in Flex, and leveraged or leveragable in your Cairngorm applications – http://weblogs.macromedia.com/paulw

Cairngorm does not advocate “chucking everything together” into a single class, and would only advocate that if that was the simplest thing that worked forthe scale of your application. i wouldn’t represent this as a a “michild of Cairngorm” , but rather that we’ve from the outset stated that Cairngorm is not prescribing the implementation of the view.

Because Cairngorm is a framework for Flex primarily, we defer to data-binding as the way of binding between a model and view, and the implementation of the model and view are both developer decisions; we only advocate the ModelLocator as the singleton through which you can locate *all* of your models.