Ted Patrick > { Events & Community } > Adobe Systems

I took a deep look at the pattern used by browsers for work on a large upgrade to PowerSDK FLOW. The browser pattern is very useful when implemented in larger scale RIAs.&

When you use a browser there is a simple series of steps that occurs from the URL request to display of the browser's view. Here are the basics from 10,000 feet:

1. Retrieve a document
2. Parse the document
3. Render a view from the parsed data via browser / plug-in components.

I believe the view presented by a browser is component based. The browser has a fixed set of components + plug-ins that are instantiated into the view by data in the parsed document. Formats like HTML are basically component instantiation data. With this mindset, layout tags (table, p, image, tr) are container components that manage child components via composition. When the view is resized, the components and containers dynamically adjust their layout accordingly.

I believe that the browser pattern is most effective when implemented within a Flash application and used to render the application view or part thereof. Over the past 2 years I have implemented several versions of the browser pattern in Flash and learned some hard lessons in what to do and what not to do in using this pattern. The Flash Player at runtime is very malleable as you can create both visible objects (MovieClips/Components) and data objects (class instances, properties, etc). In FLOW 1, I wrote a generic parser that would render components and data to a MovieClip from an XML representation. FLOW 1 had several weaknesses in that you could not bind rendering to a class, you could not create functions, and you could not subscribe to events. Although limited, I found the pattern very useful in several consulting projects. More recently in working on FLOW 2, I improved the rendering of controls and data and extended FLOW to meet the needs of larger scale RIA applications. I added support for creating functions, subscribing to events, data binding, all v2 controls, layout controls, and am adding support for an XML based little language called FX. The work shores up many of the shortcomings of FLOW and addresses the needs of larger RIA applications.

In Flash we have some advantages in using the browser pattern.

1. We can extend the components used on the client side. Instead of using the fixed components of the browser (IMG, TABLE, FORM, TEXT, Etc.), we can add new ones. With an extensible parser, this becomes a powerful way to generate the client side view of our applications.

2. We can alter the parser to handle components generically rather than committing to a "standard" that does not address the needs of applications. Standards like HTML were needed because the components and the HTML parser are hard coded in the browser. In Flash we have the flexibility to use the parser and components as we need them and as we define them. Plus in FLOW, XML is the base standard combined with the controls and handlers you define.

3. The applications are smaller as we are reusing components and the layout is never hard coded into our application. The view of the application is generated via XML. Assuming that you can deliver an app that contains components and a parser, you could render pages of components dynamically via a web server. The server would send XML and your app would render the view within Flash client side. When an event occurs, you go back to the server for another view.

4. We can render sub-portions of any existing layout. Say a user makes a selection, you can redraw a layout removing several components and adding others. This is similar to the frames paradigm, although with Flash it has the ability to work at the container(MovieClip) level. Any MovieClip can have content rendered into it.

5. We can make new components that our parser can interpret. These components can be additional blocks of XML or can be components bound into a class via composition. Assuming the parser can instantiate a class and render child controls, you can build simple components that consist of a class and some XML views defining the state of the components. This is ideal for a FormItem where an HBox wraps a Label and a TextInput control and addresses data binding. You might use XML like this,

<FormItem type="text" label="Age" dataProvider="appData" column="age" />

, to add a FormItem into a Form and add data binding. The result is that you can work at a higher level via component wrapping and composition.

In summary, I think the browser pattern is very useful to RIA development. I have used it several times with a high level of success in Flash and moving forward will be using it much more. Considering this pattern is at the heart of all Internet development over the past 7 years, this pattern is a real world proven success story. Maybe it is time to leverage this pattern in Flash to make RIA's just as successful.

I am working on a large upgrade to PowerSDK FLOW with a current consulting client. We are rebuilding an enterprise service application using Flash, FLOW, and V2 components that will ship later this year. During development, we have built an extensive toolset for rapidly building data driven apps in Flash. Over the next few months I will be showing examples of this toolset in use.

Cheers,

Ted ;)