2007
11.15

Code Behind is a somewhat vague term that means different things to different people. I believe it was originally coined by Microsoft to describe any strategy for separating logic from content in ASP pages. Using this broad definition it could be argued that the Supervising Presenter, Presentation Model and even the View Helper are all examples of the technique. So this interpretation of code-behind lacks the sort of precision we require to discuss it as a pattern.

However, one of the most common methods for achieving code-behind in ASP and .NET uses inheritance: Presentation logic is extracted out of the view class, and into the view’s superclass. The technique has been brought over to the Flex world and is arguably one of the most talked-about and advocated presentation patterns. It is this "code-behind pattern" that I am going to look at today.

Read More >>

2007
11.05

While looking at the Supervising Presenter and Presentation Model patterns it occurred to me that some people may find these concepts reminiscent of the View Helper pattern that enjoyed a spell of popularity in some Cairngorm architectures. Since the View Helper is now regarded as ‘not recommended’, I want to take a closer look at the pattern and try to understand why it may have fallen from favour.

Read More >>

2007
10.22

The next pattern I want to look at goes a step further than the Supervising Presenter by moving logic and state out of the view. Once again discussed by Martin Fowler, the Presentation Model has its roots in the Model-View-Controller (MVC) pattern.

A presentation model is an ‘abstraction’ of a view. In other words, the model represents the behaviour and state of a view, without getting involved with any of that messy graphical stuff. The view represents a projection or rendering of the model onto the screen. When changes occur in the presentation model, the view updates itself on-screen.

Read More >>

2007
10.13

Like the Autonomous View, this is another one of Martin Fowler’s patterns. He calls it Supervising Controller, but suggests the alternative name of Supervising Presenter. I’m voting for the latter for the following reasons:

  • This pattern is a derivative of the Model-View-Presenter pattern rather than Model-View-Controller, so ‘Supervising Presenter’ seems a more suitable name.
  • Due to excessive overloading, the meaning of the term ‘controller’ in UI architecture discussions has become somewhat vague.
  • The ‘Presenter’ object is neither a controller in the J2EE / Model-2 / Cairngorm sense of the word, nor does it have much in common with the controllers from the original Smalltalk-MVC architecture.

Read More >>

2007
09.30

So as I mentioned in the introduction, the first pattern I’m going to look at is known as ‘Autonomous View’. Of all the patterns I’ll cover, this one is likely to be the most familiar to Flex developers. Although Martin Fowler coined the name, the idea behind the Autonomous View pattern has been around for quite some time. For the Flex framework, the Autonomous View represents the de facto architectural pattern. If you’re building your first Flex application, you’ll probably be following the Autonomous View pattern without even knowing it.

Read More >>

2007
09.23

A recurring theme on forums like flexcoders is the issue of user interface architecture within Flex applications. Rich-client applications developed using frameworks like Flex are something of a departure from ‘traditional’ web applications, so the architectures employed for such applications will inevitably differ. But not so long ago we were comparing the new concept of web-application development with that of ‘traditional’ rich-client applications and arriving at very similar conclusions. We have come full circle, from rich-clients to web-clients and back again. So what lessons can we learn from the 20 or so years of rich-client development preceding Web 1.0? And are there web-application patterns that translate across to the rich-client world?

Read More >>

2007
01.17

Compilers have feelings too

The ActionScript 3 compiler is your friend. At least it really wants to be. But some people don’t seem interested in responding to its amicable overtures. No, they’d rather go it alone. However, keeping this clever code-cruncher on-side has its benefits: Problems detected at compile time are far easier to locate and resolve than troublesome runtime errors. So here are my ten top tips to avoid hurting your compiler’s feelings:

Read More >>

2006
05.30

If you are developing an MVC application with Flex, sooner or later you are going to want to trigger some functionality in your view when a property in your model changes. A common approach for achieving this is to use a binding tag in conjunction with a property setter in your view component. You bind your view’s property setter to the relevant model property and put your view logic in the setter function. Every time the property changes, your view logic executes.

I have never been particularly satisfied with this approach because it requires me to add a ‘fake’ property to my view component. So I created the Observe tag as a possible alternative, and I think it may also qualify as the world’s smallest tag:

package com.adobe.ac.util
{
public class Observe
{
public var handler : Function;

public function set source( source : * ) : void
{
handler.call();
}
}
}

You use the tag as follows:

<util:Observe source="{ model.myProperty }"
handler="{ this.myFunction }"/>

Because this is such a large and complex component, I need to call on the ever-resourceful Flex community to test it. So feel free to use it in your applications if you want to, and please let me know if you find any bugs.

Update: Please check Alex Uhlmann’s blog for a more recent update of the Observe tag.

2006
05.15

Flex 2 Readiness Event

Earlier this month I had the opportunity to attend the Flex 2 Readiness Event at Prisma IT’s Rotterdam office. The main goal of the four day course was to provide a broad overview of Flex 2’s features. There were fourteen other attendees, from a variety of backgrounds and nationalities: a few from Adobe, a few more from our partners, plus a few of our customers.

The course began with a comprehensive overview of the various visual controls, components and containers that are available in the Flex 2 Framework. For each new concept we walked-through an example within flex builder that demonstrated the idea.

The second part of the course was more focused on accessing server-side resources using web-services, Flash remoting and Flex Data Services. In this case the example exercises used a local jrun or cold fusion installation.

Many of the new Flex 2 features were covered in detail during the course, including contraint based layouts, E4X, drop-in item renderers and the new collection classes. In addition, changes in behaviour from Flex 1.5 were also highlighted, such as the more explicit binding mechanism and the new requirements for event dispatching.

As with the software, the course is still a beta version so to some extent we were the guinea pigs. But despite a few teething problems, the pace remained consistent. There was also talk of an additional day of lab training that was still to be added to the course, which would give participants the opportunity to gauge their understanding of the material.

Overall I felt the course represented a very thorough introduction to the Flex 2 feature set and would suit a broad audience. A more advanced course is also being planned that may appeal to more experienced RIA and enterprise application developers.

2006
04.27

Hello

Thanks for visiting my blog. My name is Paul Williams and I am one of the European RIA consultants based in Edinburgh, Scotland. Over the coming months I hope to share some of the lessons I learn working on Flex-based rich internet applications - so come back soon!