XLEFF - an XML Layout Engine For Flash

The previous part of this article introduced the very peculiar functionality provided by an XML layout engine: the ability to generate a component-based UI (user interface) by using an XML description written by you.

The Flash authoring environment already offers two valid options for creating component-based UIs:

• Build the UI manually by dragging component instances on the stage
• Generate the UI programmatically via ActionScript

You may be wondering why should you bother with creating an XML description at all. The answer is in the lack of a neat separation of the UI implementation from the application logic when you build UIs Manually or create them via ActionScript.

Separating the UI implementation from the application logic

Separating the implementation of an application's user interface from its business logic is a very abstract concept that, if properly exploited, can originate plenty of benefits.

An XML layout engine applies this idea very efficiently by allowing you to describe a complete user interface in a single text file (using the XML format).

Considering a concrete example will expose a few of the many situations in which the approach based on an XML layout engine is much more convenient than the two more traditional alternatives mentioned earlier.

Real benefits in a concrete scenario

For the sake of being practical let's assume that you have to build an application satisfying the following requirements:

PHOTO123 Limited, an international retailer of photographic equipment, contacted you to design and build a web-based application that will increase the efficiency of their supply chain from the depot to the stores.

The application should support four different languages, each of them associated with a different graphic theme matching the brand of a different pre-existing partner.

Flexibility is also a major requirement since new partners (new themes and new languages) are likely to be added at a later stage.

Similar requirements are very common when developing enterprise-size applications for the web. Creating and maintaining an application that supports several languages, different themes can easily cause bad dreams if you have to create each interface manually in the development environment or dynamically via ActionScript.

And bad dreams can easily turn into nightmares if, on top of that, your application will have to be extended at a later stage to add further languages and themes.

The benefits provided by an XML layout engine become evident when comparing its use with the two alternatives already available.

Manual creation vs. the use of an XML layout engine

Creating the UI of the sample application manually, by dropping component instances on the stage using the authoring environment, is likely to require at least four different Flash documents (FLA), each of them dedicated to the language and graphics (branding) of a specific partner.

To find a component instance in a Flash document is not an immediate action since you may need to navigate among different layers, different frames, different timelines or even different scenes.

If the UI being implemented is rather complex, even a simple task like changing the text label of a Button instance becomes a gruelling hunt.

Furthermore, if you are working with four Flash documents because of language and branding differences, you will have to repeat the same time consuming search four times!

Using an XML layout engine can reduce the number of Flash documents required to implement the UI of our example to one since both language and graphic versions can be stored in four different XML files.

Being a developer, you will be well aware that changing the text label of a Button instance inside a text file requires very little effort since a "Search and Replace" command can accomplish that in a single step.

The point of this elementary example is that XML, which is particularly good at describing nested object-oriented structures such as component-based UIs, is capable of defining the implementation a complete user interface in a single text file allowing experienced developers to exploit the efficiency and simplicity of a good text editor.

Dynamic creation via ActionScript vs. the use of an XML layout engine

There are substantial reasons that can make creating component instances dynamically more appealing than the static (manual) option.

Components acting as containers, such as the Accordion component, frequently require dynamically generated contents.

Besides, creating component instances statically becomes inefficient whenever the UI must change dynamically since those instances cannot be removed from the stage but only made invisible, therefore continuing to affect the performance of the application.

However, using ActionScript to generate a specific UI dynamically tends to produce hybrid code, which is difficult to read and, therefore, costly to maintain.

Thanks to the functionality provided by an XML layout engine, the ActionScript developer does not need to produce any code for generating the UI and can focus on the application logic producing business objects that simply use the UI dynamically created by the engine.

The resulting ActionScript code will be much clearer and much more reusable since different UIs, each of them described by its own XML file, will be able to reuse those same ActionScript business objects.

In the case of our previous example, by using an XML layout engine, a single Flash document (and its associated ActionScript files) could implement the application logic while the four UIs described in four XML files would reuse such logic.

Adding a new partner (a new language and a new graphic theme or branding) would be as simple as creating a new XML file with the same structure of the pre-existing ones but with different text content (for the new language) and different graphics (for the new branding).

Further benefits

The Photo123 scenario helped to introduce some of the most essential benefits deriving by the use of an XML layout engine.

However, the potentiality of this new approach can be fully appreciated only when applying it to a real project. The larger your application is, the more significant the benefits. Some of them are:

• Reducing the cost of maintaining complex UIs including nested components
• Facilitate the implementation of user preferences
• Ease the multiple branding of the same application
• Applications (and UIs) will become easier to modify and extend
• Speed up the implementation of accessibility requirements
• Integrating a new version of a component (or adding the support of a new component) will become a much smoother process (once done in the XML layout engine it will be reused many times)
• The XML layout engine represent the ideal subsystem where to implement bug fixes, component initialisation techniques, and any other component-based pattern (again: once done, reused many times)
• The efficient and neat separation between business and user interface logic will also make it easier to assign tasks to developers and designers, facilitating teamwork
• Style guidelines can be automatically enforced by incorporating them in the XML layout engine

Conclusion

The objective of this article was to introduce the peculiar features provided by an XML layout engine and hint to what impact those features may have in your projects in terms of benefits.

The best testimonials of this approach are the facts that several popular software technologies already adopt it and most of the biggest vendors have already announced the inclusion of this functionality in the next releases of their products.

The benefits listed here are based on my own experience and, because of that, the list is far from being exhaustive.

The combined power of XML, ActionScript and component architectures can offer unlimited options to the experienced developer and raise the productivity to unprecedented levels.