We’ve revised the guidelines section. In my opinion, one very significant new area are the Core Principles. These are principles that we feel are crucial to adhere to when developing enterprise RIAs. They are also easier to agree upon between teams even if some areas (such as an IoC framework choice) might be more difficult to agree upon. Looking for commonality between teams can help bring more consistency eventually.
Additionally, don’t forget the MAX presentations of Francois Le Droff and Yaniv De Ridder; who will touch on build automation and the impact of multi-screen on client side architecture. Afterwards, I hope we can add some outputs of it to Cairngorm.
Over the past months Cairngorm 3 has moved to a new location, the new Open@Adobe space at SourceForge. Last week we’ve released new versions from our navigation, module, integration, observer and popup libraries. The how-to documents linked through the libraries page show what’s changed and add further documentation.
If you’re at MAX, make sure you checkout the session from Francois Le Droff and Yaniv De Ridder, who will present technical insights from a large-scale RIA project built inside Adobe, which uses Cairngorm 3 guidelines, tools and libraries.
Additionally, Xavier Agnetti and Xavi Beumala will discuss FlexPMD, which is a crucial tool we use in our projects. More tools we’ve found important are linked through our tools section.
I’m excited to announce that Cairngorm 3 is released! Cairngorm communicates best practices for enterprise Flex and AIR application development, contributed by Adobe Technical Services and partners. Cairngorm is our opinion on applying modularity, IoC, agile testing, build automation and everything else we find crucial to build enterprise Flex and AIR applications. It is one set of guidelines, tools and libraries you can hand-off to enterprise development teams. Based on our own experience of many large-scale projects, Cairngorm attempts to share this opinion; early and often in order to get your feedback quicker and to advance the Flash platform in the enterprise.
Since going into public Beta in October last year, I think we’ve made a significant step towards making the guidelines coherent, many libraries robust and the tools section a best-of-breed filter for the tools we’ve been using successfully in practice. This is a living project! Expect changes as we’ll receive feedback and our own thinking evolves; Cairngorm will evolve. Cairngorm is a success for us, if it portrays what works for us and can work for our partners and the external community leveraging the Flash Platform.
Cairngorm starts here.
I’m excited to announce that we’ve redefined Cairngorm to increase its scope. Tom Sugden announced our intentions here last month. We’ve now published the first content on opensource.adobe.com.
Instead of only providing a specific implementation of an MVC architecture, our team within the Adobe Technical Services organization took a step back and collected some of the most important knowledge that helped us deliver enterprise Flex applications over the last few years of consulting projects. This includes modular application development, layered architecture, domain-driven design, loose coupling, quality guidelines, build automation strategies, agile testing, code coverage best practices, and more. We present Cairngorm in three parts:
Often I see the question coming up on whether to use MXML Script blocks, Code Behind or Helper classes.
I think the question behind the question we’re addressing here is not whether to use Code Behind, MXML Script blocks or View Helpers, but is actually where is it best to place functionality in a Flex application.
But first of all, let’s have a quick rundown on what Code Behind, View Helper and MXML Script blocks actually are:
In my last post about the Cairngorm Dashboard example I’ve added a little functionality that allowed a view to react to a state change in the model in order to do something view related like invoking a popup or an effect.
I’ve been using the binding approach and that made it very easy and flexible to do. But as I said in my last post, this can have one slight drawback you have to consider. In this post I’ll showcase the drawback and provide a solution to it via an extended version of Paul’s Observe tag. Furthermore, this extended version of Observe makes it even easier to perform this kind of listening to the model.