slide framework and the zeitgeist

As I've recently started talking to people about Slide, it's becoming clear that none of the ideas are new. Here are some examples of that.

We used to call our Presentation Models "View Delegate", but I found that lots of people were using the same identical pattern and I recently changed it. The new name is a lot more descriptive (and more familiar to developers too).

A week or two ago, I was talking to Nigel Pegg and he mentioned that he had done a big refactor in a project he is working on, just before I blogged about Cascade. He had removed singletons and replaced them with a very similar cascade mechanism.

Several people have emailed me, or come to talk to me after my presentations, to say that they are also using global URI-based view state mechanisms. The implementations vary dramatically but the basic idea, of using a URI for a state hierarchy in order to decouple knowledge of views from controllers, is the same.

Richard Leggett (also one of the people using global view state URI's), reminded me that our IAppProps interface is actually an Application Context. Other platforms use the same idea but under a different (better) name.

Overall, I'm very happy that we are making Slide open source. This sort of feedback validates our approach and gives me confidence that Slide will be useful and relevant to other people, and that I'm not on some wacky tangent from reality. But, even better than that, this feedback is already helping us to improve what we have. Whether it's better naming suggestions or, maybe in the future, insights into better implementations, we really can't lose out.

presenting at london flash platform user group

Johannes Nel and myself will be presenting tonight at the London Flash Platform User Group. I will be giving a version of the talk I gave last week in Sydney, about our Flex application framework, Slide. Johannes will be talking about some of our recent experiences with working with large data sets.

Slide framework preview part 2: cascading properties

Slide is view-oriented. Along with the view state management, it recognises that Flex apps are often modular and that these discrete pieces are mostly MXML components.

The Slide framework evolved from a set of classes that we were using over and over. And as we used them we realised that references to things like the StateManager were needed by every view, but using a Singleton was not the best solution. Firstly, a Singleton StateManager would make it impossible to write reliable unit tests against our views (since the StateManager is, by definition, stateful you couldn't assume that previous tests didn't have a permanent effect on it). Secondly, if we wanted to have separate autonomous pieces in the application, they'd still be tied to the same StateManager instance and would have to be in the same state as each other.

For maximum flexibility, we wanted to be able to set properties on a view and have all child views be able to access that property, but still be able to override it for themselves and their own children. To do this, we added a special metadata tag, [Cascade], which we use to annotate properties on views, which means that the value for that property cascades from wherever it is set to all the children. For example, a reporting application might have a view structure like this:

You can choose between viewing a report or looking at your report history. A report has a summary and a chart. The report history just shows the summary for each report and uses the same Summary component that is used in the report itself. Each of the components in the tree has a binding to currentReport and uses different information from it.

When the report changes, you would have some code that does something like:

mainView.currentReport = theReport;

And, for each view, you would have the following line of code (or, more likely, you'd put this in the base class that is used by all views):

[Cascade]
[Bindable]
public var currentReport:ReportModel;

And now all the views will now have access to that report. But then all the items in the History View will be the same. So the ReportHistoryView can override this property for each of it's children. Perhaps something like this:

<mx:Repeater id="historyRepeater"
    dataProvider="{reportHistory}"
>
    <ReportSummary
        currentReport="{historyRepeater.currentItem}"
    />
</mx:Repeater>

This example is a little contrived, as ReportSummary would probably just have a normal attribute to set the report it needs to display, which you'd set from the parent component. But when you are dealing with many complex components that all need to be configured with many properties, you quickly start making savings in the amount of code you have to write, in particular in the amount of very similar code that you have to write. You only have to configure them individually if they are different from the parent.