Recently in Best Practice Category

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.