Monthly Archives: January 2005

The Browser Pattern

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,

, 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.



Remove _global from Debug > List Variables

I use Debug > List Variables while debugging. If you use V2, there is a ton of _global objects and classes that get created. Here is how to hide them from Debug > List Variables.&

//Paste this line at the top of your v2 app

//No more _global in List Variables output

ASSetPropFlags( _global , null , 1 , 1 )

Another side effect is that Debug > List Variables takes far less time. Happy debugging.



100 days of XTreem

One hundred day have past since XTreem was publicly released and I am about to dive into development again.&

Since the last patch release (.976) I have been accumulating requests for feature changes and bug fixes here is the big list:

1. Licensing – Clearly state there is no spyware in XTreem. Edited XML is never sent from XTreem onto the Internet.

2. Direct XML Editing – In the XML edit pane, users would like to directly edit the XML and have it reparsed into the tree view. If a parse error occurs the user would be alerted and have the option to revert to pre-edit conditions or fix the XML.

3. Tab/Whitespace Toggle – Similar to TextWrap the user would have the option to remove tabs from XML output.

4. File Close – There is no way to close a file and clear memory. By default XTreem persists the last edited document when it is closed.

5. Speed up XML processing – I am planning to add caching to XML along with dirty flags. When a node is edited, the node will be reparsed and cached. Only nodes marked dirty will be re-parsed when the a view is requested.

6. Documentation – Xtreem will get its first help documentation with this release.

7. Clean-up the UI

8. Switch everything over to V2 EventDispatcher/delegate, there is a bug in the component shared libraries.

9. After dialog closes, focus returns to attribute grid?

If you are interested in testing the development version, just send and email to ted[@]powersdk[.]com.

Here is a chart of the first 100 days of installations. The yellow to the total installs while the purple is the daily downloads amplified by 500%. Since day 46 the daily download rate has been growing steadily.



Flex on the command line

I am a big fan of the command line. There is nothing as pleasing as typing some commands and compiling an app. So I located the MXML Compiler in my Flex installation and one argument later, SWF.&

The Flex MXML compiler is located at Flex\bin\mxmlc.exe and simply passing this exe valid MXML document will result in a SWF file:

C:\Flex\bin>mxmlc test.mxml

Depending on your licensing, the SWF will have an expiration time or not. If Flex licensing is in developer or trial mode, the swf will expire within 24 hours. I expect the SWF below to shrivel and die at 9AM tomorrow.


WARNING – Above data is highly subjective and fake, some may find disturbing!

Also depending what you use within your MXML, the swf files may be portable to other http servers. Above is an example that I compiled this morning. It is being served by my FreeBSD server over http. This type of portablity is sorely needed in Flex. I have personally had 2 clients who could not use Flex for this very reason, yet were willing to pay for licensing. If licensing would allow me to create portable SWF files, I would purchase a FLEX license for PowerSDK in order to service consulting clients more fully. Combined with AriaWare Optimizer, I could generate very small SWF files for clients and reuse the base components via shared libraries.

Correction: Ariaware Optimizer is not yet compatible with Flex output as the __Package paths are different than the V2 framework. I ran the SWF output through Ariaware to test and although it states it work, it fails to partion classes in to separate file. Sorry for the confusion.

So what is so great about the command line? It is scriptable, consistant, simple, strict, extensible, and very precise. There are thousands of tools that can be integrated from the command line and writing your own command line tools is easy.

Fire up the command line and compile some MXML!



IArray – Iterator Array

I am a big believer in making things simple. I wrote this class a while back to simplify looping over array contents. It makes looping over an array easy, much more logical, and less prone to error.&

The IArray class can be found here:

To loop over an IArray’s content you simply pass a function or method to the ‘iterate’ method as follows:

//create an IArray

a = new IArray()

//add some items to the IArray

a[0] = ‘Zero’

a[1] = ‘One’

a[2] = ‘Two’

a[3] = ‘Three’

a[4] = ‘Four’

a[5] = ‘Five’

//create a function

f = function( a , b ){trace( a + ‘ ‘ + b )}

//iterate over the IArray

a.iterate( f )

The iterate method will call the passed function with 2 arguments, rowNumber and rowObject allowing your function to do as it pleases.

You can also iterate over the items in reverse:

//iterate over the IArray and set the reverse flag to true (default is false)

a.iterate( f , true )

You can also iterate and modify the scope of passed function:

//iterate over the IArray forward in the scope of _level0

a.iterate( f , false , _level0 )

I find that it removes gobs of, for, and while loops from dependent classes and makes iteration over an array much simpler and predictable. Plus since it works consistantly, your dependent code is less prone to error. All you need is to pass a function to iterate and off it goes.



Duct Tape Observer

On Flashcoders, someone asked the difference between EventDispatcher and the Observer pattern. Patterns are guides, getting em to work practically is often a different story. Here is my take. Happy New Year!&

Duct Tape Observer

It isn’t class based, it isn’t pretty, but it works, just like Duct Tape. Just paste and compile.



//make sure to import EventDispatcher


//what we will watch for changes

theObserved = true

//create an ‘observer’

//this will watch ‘theObserved’ and tell anyone interested it has changed.

observer = {}

//add eventDispatcher methods to ‘observer’ observer )

//add a watch to dispatch an event from observer

watch( “theObserved” , function(a,b,c){

observer.dispatchEvent( { type:”change” , name:a , newValue:c} )


//create a listener

//the ‘observer’ will tell this listener when something happens

listener = {}

//create an event to be called by the ‘observer’

listener.change = function(eo){

trace(‘The observer said “‘ + + ‘” changed to ‘ + eo.newValue)


//add the listener to the observer

observer.addEventListener(‘change’, listener)

//change the value of ‘theObserved’ to test

theObserved = false

theObserved = true

theObserved = “OOOOH”

theObserved = “AAAAH”


Now get out there and observe something!