Ted Patrick > { Events & Community } > Adobe Systems

One of the recurring problems with Flash is that there is no structured way to layout movieClips in bulk in a consistent programmatic manner at runtime. Although we can pre-build all the layouts in separate frames or movieclips, there is a distinct disadvantage in that an existing app must be recompiled to extend or modify the layout. Assuming that Flash had programmatic extensible layout engine, the range of possibilities expands dramatically. This is essentially the goal of the FLOW project.

Ideally with minimal assets in the library, just components, one could render a layout and re-render a layout at any node (movieClip) based on data. This would be similar to allowing a web page to re-render a whole page or a certain aspect of a table without a full page refresh. In one sense you gain the ability to easily script many components in a particular layout and in quite another, you can render internals of a component.

With Icon Builder, I made an important discovery in how to integrate this sort of nested rendering. Icons made from Icon Builder are ASCII strings that are rendered through the drawing API, as such they require a container movieclip. I was asked late in the project how Icons could be integrated such that they would act identical to Movieclips, but without the linkageID or library asset.....

Four days later over beers....Ding!

Instead of adding each icon to the Library under a linkageID, you could inverse the problem and instead interpret arguments passed to the attachMovie method. By replacing the attachMovie default method with a backward compatible substitute you can support extended functionality when attachMovie fails, but before execution is returned. This allows you to perform allot of work in the middle of the execution of attachMovie, potentially adding 50-100 movieClips and TextFields based on an XML document.

Wrapping AttachMovie Example:

a = MovieClip.prototype.attachMovie

MovieClip.prototype.attachMovie = function(){

var mct = MovieClip.prototype.attachMovie.old.apply( this, arguments )

trace("Mid attachMovie Execution!")

//test mct for failure or do something else!

return mct

}

MovieClip.prototype.attachMovie.old = a

delete a

_level0.attachMovie('ted','ted',0)

What is interesting about this solution is that it is easy to make work in a recursive pattern by cascading nested rendering to inner executions of the attachMovie method rendering down the tree. Also this needs to be open and extensible allowing new components, classes, or movieClips to be supported easily.

What really became interesting in FLOWS's development is when data enters the picture. Applications always represent the memory state both components (visual) and data and if you can render both (in proper instantiation order), you can create powerful applications quickly from ASCII Text (XML). It even becomes possible to save state in particular application without the mess.

The Flash Player organizes content in a tree structure that changes over time. Anytime you are viewing a movie, you can always represent the content you see as a tree. Although strangely, it is the inability to duplicate the tree dynamically at runtime that I see as Flash's next big challenge.

My current thinking is to put both FLOW and PRIM into public hands under and open source license and do consulting! ;0

Cheers,

Ted ;)