Flex Roadmap – Back to the Future, Part 1

One of the most interesting sessions during Max 2007 was Ely Greenfield’s “Flex RoadMap” . It actually had a flair of developer-to-developer conversation rather than a demo or promotion – more on “why” Flex Team is moving in this direction. Unfortunately, the feedback from the audience was rather weak as most of the people were stunned by the approach taken. I felt compelled to compose my thoughts and re-evaluate my experience before I will come with any feedback on the subject.

The reason being that we walked that road in the past; we still are using that methodology in our Flex work. Having support for it from the tool vendor will change both adoption rate and the way people approach it.The idea behind new set of tools in development is pretty powerful and simple:

Take large controls that we have in frameworks and libraries and layer them in relatively small and specialized layers of loosely bound reference implementations.

The layers can be UI elements, skinning, layout, data binding, view controllers, etc that compose a typical framework control. Each layer is completely replaceable or better yet each control is being assembled for an application from “parts” by a team of designers, programmers, model designers, etc. As long as it can be expressed as an XML markup, design tools can produce these layers thus providing interchangeable implementation of design or other aspects.

We used this approach as core methodology in the past and were very happy with the results. In the beginning of RIA era (1999) IE version of DHTML had so-called “behaviors”. You could have attached these XML/script combo components to any tag or create your own tags. They could be small – just to add a presentation/effect like rollover or provide intelligent links or tooltips. We also had the “monster” ones representing DataGrid, Report, Tree, and TabFolder to name a few. You could have attached multiple behaviors to a single tag providing control with a superset of functions – the same rollover/selection effect would work on DataGrid and Tree in the same way.

Data binding was just another behavior shared across multiple controls. Within a year after adoption our home-grown framework had over a hundred of such components that we customized and delivered to clients in a way that was the most beneficial to them. We’ve also built an IDE to support these components, but for me it was simpler to “notepad” it with a smart XML editor.

It was a very simple model as it was built on top of C++/OLE world supporting multiple inheritance/vtables. Each behavior would automatically expose its public methods, event model and properties. The order of attachments would define the priority. If you wanted to specify particular behavior, you just use behavior name as intermediate selector before property/method name. You can even layer different languages as behaviors – we would use XSLT styling as one of the behaviors. That was the simplest aggregation model I ever seen in world of C++/OLE or anywhere – even in the modern dynamic languages.

Flash 9 VM does neither supports multiple inheritance nor dynamic resolvers (to the best of my knowledge), and Proxy approach might not be good for regular application developers. Now it might be a good time to start adding that functionality back in Flash 9 sub releases and definitely in the Flash 10 to go head-to-head with rails and other modern languages. You really need to apply aspect based programming methodology on system level to afford this approach – or have tools to do it under the cover. However, I feel that the tools approach will take longer and will cause slower adoption.

The power of externalizing the functionality is just awesome. You clean up a lot of code, and get more choices in the process. Reusability of the code becomes obvious. It takes some time to learn, but it makes you a better thinker. All cumbersome patterns go away as you concentrate on one thing at a time.

We never gave up on this architecture, and it proves to be the most powerful feature of our current framework of Flex components. I will publish some samples this week to show how trivial the code looks like in comparison to typical Flex programs yet delivering more functionality.

Ely presented architectural diagrams illustrating how things are interconnected now and how they can change in the new architecture, and I could not help seeing it as a live biological system going through a major transformation. Application components are the cells of the living and breathing application. In the current development we are integrating more and more specialized creatures without their own DNA (hence viruses) directly in the cells using ever extending set of backdoors. Managing viruses is a nasty business, taking all kinds of the resources. Proposed architecture is more of bacterial helpers, attaching to the cells, but not breaking in, exchanging energy and processing waste. It holds better promise over brutal methodology of “gene engineering” and provides open space of growing specialized “cultures”. Count me in.


Anatole Tartakovsky