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:
For everyone who couldn’t attend my MAX presentation in Las Vegas, here is the presentation as PDF. Furthermore, I’ve released the complete source code for every effect shown.
And here is the Flex 2.0.1 version.
Behind the scenes, these effects are using the DistortImage utility from the open source 3D Engine Sandy. Make sure you check out Sandy if you haven’t yet! The effects included are called Flip, CubeRotate, Push, Pop, Door and Gate. But instead of talking about them, just see them in action for yourself:
This sample application lets you play with all effects available. You can also see different configurations, i.e. try enabling the blur checkbox.
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.
In the last post about this topic, I’ve added some functionality and another use case to our stock quote application and showcased how a Cairngorm application could scale with focusing on creating model objects. In this post I’ll perform some further refactorings to our model objects.
Furthermore, our customer wants us to show a pop-up as soon as a successful stock purchase is being made. I’ll cover how a state change in your model can transparently cause view related code (like creating a pop-up) to be executed.
As MAX 2006 in Las Vegas is coming closer and it’s shaping up to be a fascinating conference. I’m talking about
Leveraging Flex 2 and Flash Player 9 for Truly Cinematic Experiences
and I’d like to give you more information where this will be about, in hope you consider joining my session!
I’ll talk about how cinematic effects can dramatically improve the user experience of a Rich Internet Application and can contribute significantly to the success of how your RIA will translate the experience that your costumer wants to deliver.
You will see new types of effects and learn best practices toward their use and creation.
The goal of this series is to demonstrate how you can manage views with investing in your client side business logic.
The previous posts (part 1, part 2) were primarily about the infrastructure of a very simple single and multiple view dashboard application. This and the following posts will add further functionality to the application with the indent to demonstrate how your model objects become a focus point of your application.
In particular, we’ll add validation logic, formatting logic and an additional use case.
UPDATE: The Login example has been updated by Neil Webb to Cairngorm 2.2. Check out his series of articles explaining Cairngorm using the Login example.
I’d like to give you early access to a new version of the CairngormLogin sample, which we’ll ultimately make available on Adobe Labs. We’ve been releasing this very simple example application in earlier versions of Cairngorm alongside the framework code. Intention is to showcase how to get a simple Cairngorm application running. Furthermore, I’ve also upgraded my dashboard samples, which I’ve shown in previous posts.
Earlier this week Cairngorm for Flex 2 has been released. There have been a number of changes compared to Cairngorm for Flex Beta 3. This post intents to explain some of what’s changed, why it changed and how you can handle the changes for migrating your Cairngorm applications to the newest version. Sorry for the delay of this post, but as you might know, there’s a fantastic soccer World Cup in Germany going on these days.
In the last post I’ve introduced you to the stock market dashboard sample application and how you can create business logic to manage your view. In this post and example, I’ll apply another use case to the sample application. With adding multiple pods to the stock market dashboard, the user can request price quotes independently. Each pod has its own stock market data. I’ll cover how your business logic can be adjusted to manage each view. I’ll also touch on how stateless Commands can help making this application easier.
There are many ways to update your views when your server- or client side business logic changes. The strategy you find me usually recommending is the ModelLocator strategy, which leverages the Flex binding feature. See Steven Webster’s article for more information.
Basically, your views bind to properties that are retrieved from your ModelLocator. These properties can be changed from your Commands, other business logic or other views and once changed; all listening views are updated seamlessly.
Since many of the Cairngorm examples out there are meant to be easy to understand, they often just show these properties exposed as single properties on the ModelLocator. Once your RIA grows in size, this indeed can be quite limiting. I’ll showcase another Cairngorm sample application that focuses on how you can improve your architecture with investing in slightly more advanced business logic. The sample application is a stock market dashboard that allows users to retrieve price quotes on a company stock. From time to time I’ll add features to this application, to showcase some possible ways to architect a Cairngorm application. This version of it will use Cairngorm for Flex 2 Beta 3.