Monthly Archives: June 2003

PowerSDK V16 Alpha 1 Examples and Distribution


I posted an Alpha Distribution of PowerSDK V16 with examples.



PowerSDK Development Site:

About PowerSDK

PowerSDK V16 is a major release and much of the old engine has been rewritten and replaced. I will be posting additional documentation and examples as we move ever closer to a production v16 release. Feel free to download the examples and play around with the framework. PowerSDK is free software and supports a BSD License.

I would like to thank Robert Penner for contributing his legendary Easing Equations and Color Libraries to PowerSDK. They are included in the PowerSDK distribution under:



Anyone who wants to include runtime components within PowerSDK is more than welcome to contribute. Several distribution options have been added to allow you to openly contribute software to the PowerSDK Framework as follows:

1. Source contribution under PowerSDK BSD License

2. Binary contribution under PowerSDK BSD License

3. Source contribution under custom License and Copyright

4. Binary contribution under custom License and Copyright

These options were added to increase the number of runtime components available for PowerSDK. If you are interested in making a contribution to PowerSDK, simply contact me at Component authors are free to use the base PSDK infrastructure within your components making them smaller, faster and more reusable.ūüėČ

If you have any questions or comments about PowerSDK, please do not hesitate to ask.

More to come.ūüėČ


Theodore E. Patrick

PowerSDK – Code for a distributed world

Versata Business Logic Server

I have been working with several Versata products lately. In short, it has completely altered my perspective of server-side development.

Versata uses business rules as a development metaphor. A developer writes rules and generates software from these rules. Change a rule and all dependent software changes. Within larger applications, this allows you to change very complex systems very quickly.

The theory behind Versata products is that duplication/embedding of a business rule into software reduces software quality and eliminates reversibility (undoing what is done). As we write software, we embed rules in hundreds if not thousands of places. Even worse is the fact that we often duplicate common rules across several applications. When rules are extracted from software, they can be effectively shared like a component. The real key in Versata is that you can replace 90% of the software we write with simple well organized rules.

Take following rules for an HR application as an example:

Employee has ssn, name, salary, age, hireDate, phone, address, sickLeave, vacation

Employee.overTimeSalary equals Employee.salary*2

Employees are Payed every 2 weeks

Managers can Add and Remove Employees

Employees get 2 weeks SickLeave per Annum

Employees get 2 weeks Vacation per Annum

These rules could be used to broker database updates, web services, and UIs in a multitude of applications. Although similar to OOP, rules are more flexible as you can defined relationships between classes on a transaction basis without changing the classes. Essentially the class is oblivious to the rules in use and when a method is called, the arguments can be manipulated by rules prior to the methods execution. In short, it allows for very simple classes and database tables.

Having used the toolset, Versata would be an excellent addition to the Macromedia toolset. Plus Versata (VATA) has a 12M MarketCap, 16M in cash and positive cash flow. That is quite cheap considering the technology is nothing short of excellent.



ID Card Printing RIA – 20 Minutes

The British High Commission, here in Jamaica, needed a simple application for printing Identification Cards. Here is a modified version of the application:


1. Output to Fargo ID Card Printer

2. Easy to use – Office personnel could make ID cards without training

3. Custom templates allowing the design to change easily.

4. Capture photograph “Live” from Web Cam

5. Data entry provides visual feedback

6. Photo loading, scaling and repositioning (Drag the Photo/Video + UP & DOWN Keys)

This application replaced 4 installations of MS Publisher / Fargo CardMaker and allowed anyone on the intranet to produce ID Cards. It also eliminated 15 minutes of production time per card and dramatically improved output consistency, minus the occasional missed photograph.

Plus it only took 20 minutes to make.



Optimizing _Global lookups

Whenever you look-up a variable in _global, the Player uses scoping rules to find an answer as follows:

1. Look locally

2. Look up the inheritance chain recursively (“follow the __proto__”)

3. Look in _global

4. Else return undefined

As _global is last location where something can exist, if you know it is there, it makes sense to use _global to avoid steps 1 and 2.

Here is an example. This code is called within a MovieClip say _level0:


1. Is Math local? No

2. Is Math in Movieclip.prototype? No

3. Is Math in Object.prototype? No

4. Is Math in _global? Yes Return



1. Done


Another optimization is to reduce the number of bytecode instructions by using slash notation. It is important to recognize that a reduction in the number bytecode instructions will directly improve player performance. Although I personally reserve slash syntax optimizations for performance intensive code like components and system level functionality. It doesn’t make sense to use slash syntax all the time. Here is an example:



//Bytecode via Flasm

push ‘_global’


push ‘Math’





//Bytecode via Flasm

push ‘/_global:Math’



I conducted some tests to challenge my conclusions. This code loops over a _global lookup for the Math Object 10000 times 4 different ways. The tests were timed to compare different syntax usage. Here are some typical results:


a:245 Math.a

b:263 _global.Math.a

c:212 /math:a

d:209 /_global/math:a








Math.a = 23





_global.Math.a = 23





/math:a = 23





/_global/math:a = 23




trace(‘a:’+(a1-a0)+’ Math.a’)

trace(‘b:’+(b1-b0)+’ _global.Math.a’)

trace(‘c:’+(c1-c0)+’ /math:a’)

trace(‘d:’+(d1-d0)+’ /_global/math:a’)



Laszlo Server & Authortime vs Runtime Components

It is interesting that most of the features of Laszlo Presentation Server can be accomplished client-side with the v6 Flash Player! This was essentially the same “death blow” that ended Generator as a product. I’m surprised Laszlo made the same mistake.

Hopefully MM will avoid this error with Royale. MM tends to learn from their mistakes. Obviously Central will be infinitely better because of ShockMachine, even though SM is dead and gone.

Laszlo is a server-side component toolkit for creating swf applications. You define applications in XML and the server complies server-side authortime components into one big swf when an application is called. The “One Big Swf” approach implies that there is very little client-side runtime component reuse. Although, you should be able to extend Laszlo to support it. Laszlo provides an nice development paradigm for writing component based applications via XML. Each tag represents a component with properties/events and components can be infinitely nested.

Authortime components tend to lock a developer into using a particular development methodology. Lets fact it, FUI Components were designed to lock us into using the Flash MX IDE and Laszlo’s components lock us into using their server. This is ok if you “LOVE” the development methodology but is not ok if you want flexibility. Although subtle in its presentation, marketing, and use, authortime component create an addiction. I must add, in all fairness, that authortime components make things easy on the developer by providing a component specific interface while authoring. Although there is no reason one cannot merge these two extremes and provide an authortime interface for using runtime components. Actually, this is the purpose of Branden’s Outlet component and the design-time libraries of PowerSDK.

Runtime components allow you to reuse a common component across many applications without requiring the client (Browser/Player/Central) to download it again and again. At authortime you specify where, when and how you want a component to appear and at runtime the component is imported and displayed as needed. Although difficult to set-up initially, this technique allows you to use components across many applications on a common domain regardless of how they are originally authored (Laszlo, FlashIDE, Royale, etc..).

After all, the Flash Player is a component framework itself. Allowing a swf to load a swf into itself is the ultimate form of component reuse. This will always be one of the best features of the Flash Player. When it was added in version 3, it simply changed everything.

Thoughts and comments always welcome.



PowerSDK Process Class

I have been designing a Process Class for PowerSDK in order to add control over execution of long or short running functions in a predictable manner. The concept is to provide a class that handles most of the mundane loop logic so the functions are simpler and easier to manage long term. This is similar to how the quicksort works in Flash as the sortTest is a functional argument on a generic quicksort implementation.

Below are a simple set of cases that describes the types of functionality I want to cover.

Cases or “different ways to execute a BackFlip…”

1. Iterate – Execute a function a certain number of times

“Do 10 Backflips

“Do 1 Backflip for every letter

“Do 3 Backflips for every user

2. Interval – Execute a function after an amount of time/frames

“Do a Backflip every minute

“Do 3 Backflips per hour

“Do 2 Backflips every 3rd frame

3. Event – Execute a function when this happens

“Do a Backflip when this happens

“Do 2 Backflips every 3rd time this happens

4. Alarm – Execute a function at this time

“Do a Backflip at 10 AM daily

“Do 3 Backflips at 12 noon Monday Weekly

5. Alarm Range – Execute a function repeatedly across a time range

“Do Backflips from 10:13AM to 10:20AM daily

6. While – Execute a function while this is true

“Do Backflips until this is true

Creating a process

  myProcess = new PSDK.Process( function, arguments, cycle )

  function Р(function) pass a function

¬† arguments – (array) pass static or dynamic arguments. Dynamic arguments are eval’d at execution.

  cycle Р(object) pass the pass a function

Start and Stop a process











We will see where this leads….



Wrapper Constructor with events and substitute arguments

I wrote this constructor function that produces wrapper methods. It returns a wrapper for the function passed as an argument. The key is that it allows you to append events on either end of execution and substitute the arguments array. It is a fairly simple way to extend functions in-situ via events or conditionally modify the arguments array on execution.

// wrap the trace method

a = wrap(trace)

//NOTE: ‘new’ breaks the functionality as return is ignored.

//execute it

a(‘Hello’) //output: Hello

//add some events

a.onstart = function(a){trace(‘a.onstart ‘+a)}

a.onend = function(a){trace(‘a.onend ‘+a)}


//output: a.onstart Hello

//output: Hello

//output: a.onend Hello

//add a substitute arguments object

a.arguments = [‘New Hello’]


//output: a.onstart Hello

//output: New Hello

//output: a.onend Hello

Or how about wrapping a method of MovieClip.prototype

MovieClip.prototype.getDepth = wrap(MovieClip.prototype.getDepth)

MovieClip.prototype.getDepth.onstart = function(){trace(‘before’)}

MovieClip.prototype.getDepth.onend = function(){trace(‘after’)}

Here is the wrap method:

_global.wrap = function(s){

  return function(t){

    var self = arguments.callee

    var r


    if(self.arguments) {

      r = s.apply(this,self.arguments)


      r = s.apply(this,arguments)



    return r



a = wrap(trace)

a.onstart = function(a){trace(‘ a wrap onstart a:’+a)}

a.onend = function(a){trace(‘ a wrap onend a:’+a)}

a.arguments = [‘a custom arguments’]

b = wrap(a)

b.onstart = function(a){trace(‘ b wrap onstart a:’+a)}

b.onend = function(a){trace(‘ b wrap onend a:’+a)}

b.arguments = [‘b custom arguments’]

c = wrap(b)

c.onstart = function(a){trace(‘c wrap onstart a:’+a)}

c.onend = function(a){trace(‘c wrap onend a:’+a)}

c.arguments = [‘c custom arguments’]