AS3 and rules based engines

Posted on October 21, 2008


In 2003 / 2004 I developed the “Fluid Flash Interfaces Engine” (FFIE) which I sublabelled “the poor man’s Flex” when Flex was released. Based on XML definitions and rule sets it drew all GUI-elements, made them interact, present data and connect to datasources.

The idea behind the FFIE was that 95% of all basic logic behind data-driven sites can be captured in generic abstract layers. This includes:

  1. Basic interaction models
  2. Data handling (retrieving and sending)
  3. Screen elements / GUI elements

Using XML you can then glue things together.

Simple form of a Rule Based Engine

In the most simple form a Rule Based Engine is using the “if then else” / “select, case, default” statements to define what is required based on abstract descriptions given in – say – XML.

It has the flexibility to create main sets (like screens) and nest subsets (like forms, form fields, Scroll Panes and buttons) all based on the structure of the given dataset.

Behaviors within each element are pre-defined and activated or linked using “settings” per element. For instance, a single XML-node could be reading:

<scrollist src=”datasets/mydataset.aspx” scollelement=”people/scrollist_profile.xml” onClick=”showPerson”>

In the rule based engine, this node is translated to:

  1. Get and present the Scrollist Asset on stage
  2. Set the datasource of the Scollist Asset to “datasets/mydataset.aspx”
  3. Present the data using the XML definition stored in “people/scrollist_profile.xml”
  4. When an element is clicked, address the asset with ID showPerson and invoke the “call” event with all parameters stored in the listitem.

Using extra parameters, you can define X/Y position, style settings (borders, margins, hearer-type, colors, textures and so on)

Resolving linkages and data transmission

In contrary to OOP practices the Rules Based Engine uses loose binding in the Glue between every component. The datapackage sent is XML or a generic Object. Component “A” simply assumes that Component “B” can read and unpack the data “A” sends to “B”. Component “B” just takes anything sent via the Glue and picks those elements it expects to recieve. When some parts are missing, it either compensates with default settings, throws an error or simply does nothing.


Communication between parts is again based on rules. Do you think verification is required based on typing: add a “type” attribute to your package and refuse anything not of that type. Is it to no relevance: leave it.

Extending the example

As said, the XML (data) structure can be used to define the appication structure. So in abstract form, your application structure could look like:

– Application
– Menu
– Menu items
– Screens
– Screen
– Form
– Gui-elements
– Screen

Where each screen element is linked to a menu-element using a logic ID.

Each form and screen can have a set of default settings based on a graphic design. Each element on screen can have a default set of behaviours, extended or overriden by extra behaviours as stated in the parameters given per item.


A Rule Based Engine is nothing more than an extra abstract layer on your existing code base / application / class libraries / framework using parameters and structures to address specific classes and objects in your framework. When done properly building stuff will be reduced to XML nodes stating: “give me this and that, bind ‘A’ to ‘B’ and ‘C’ and go for it”.


  1. Zero coding: Yeah… …that is: zero coding in your front end applications.
  2. Re-usable logic: When done properly, your Rule Based Engine is a growing library of generic tricks, procedures and behaviours. The stitching is done via your XML-datasets or whatever source you choose to use.
  3. Increasing Intelligence: once you have made this framework for interactions between elements, you can re-use it, make it smarter, make it more flexible, more varied, more solid, more communicative and so on.
  4. Rapid Application Development: Because you boil your applications down to rulesets encapsulating your classes, called by abstract definitions, and all the things you already included in your Rules Based Engine you can build more and more complex applications using the “glue” of defitions, rules and behaviors
  5. Rapid Change: since all you need to change is the structure of your (in our case) XML set and all logic is placed in pre-compiled modules you plug together using paremeters, shuffling elements around does not affect any code and (depending on the solidness of your work) does not introduce new errors.

When to build it

Rules Based Egines are useful when:

  1. The same logic is re-applied over and over again
  2. Coding starts to look like Copy & Paste.
  3. New implementations are variations on themes.

Where I used it

  1. To build complex data driven web sites in Flash with tabsheets, forms and lists
  2. To reduce the coding for sites using multiple data databases, multiple datasources per web-page, caching and states per data-item on the page.
  3. To build Quiz-engines

Extending the rules

Any piece of software comes to existence to growth and evolution based on the work of the programmer and the feedback from the environment. So when you need new stuff, you extend your Rules Based Engine. You extend the possibilities and you extend the number of parameters you can set.

To be continued…

Posted in: Uncategorized