Simon Wacker

As mentioned in my previous article, the IoC container for Flash supports two XML dialects: a simple one to wire up business objects, and another less verbose one to build user interfaces (with any user interface framework or component library, including in-house ones, that follow some common coding practices).

Following is the ErrorWindow.xml from the As2lib Chat sample application:

Namespaces are declared for packages that contain needed components: namespace ‘chat’ is mapped to package ‘org.as2lib.sample.chat’ and ‘aw’ to ‘org.aswing’.

Beans can now be declared as elements with one of the declared namespaces and the class name as local name: <chat:ErrorWindow …/> or <aw:JPanel …/>

Properties can either be elements with the element name as property name (<messageLabel>…</messageLabel>) or attributes (actionListener=”…”).
Note that there are some reserved attributes like ‘id’, ’style’ and ‘class’. If a property has the name of one of these reserved attributes, it must be declared with an element.
You may have noticed that not all inner bean definitions are wrapped by a property element. For example the ‘JLabel’ and ‘JButton’ beans inside the ‘Container’ bean. So to which property of the ‘Container’ bean are they set? To the default property! If you parse the ErrorWindow.xml with the ‘AsWingBeanDefinitionParser’ the default property is ‘append’ which fits most needs. If you just use the ‘UiBeanDefinitionParser’ there is no default property, but you may specify it with the ‘default-property’ attribute in the root element as global default-property and/or in any bean definition as local default-property.

Property values with one of the following patterns are interpreted in a special way:
* p{} or {} is a property get access: {messageSource.message[title.error]} is interpreted as messageSource.getMessage(”title.error”)
* r{} is a bean reference: r{messageLabel}
* d{} creates a delegate: d{errorWindow.hide}
* v{} retrieves a variable: v{org.aswing.WindowLayout.TITLE}
* m{} invokes a method

The reserved ’style’ attribute maps a bean definition to a style class in a style sheet. Here’s an excerpt from the style.css file of the As2lib Chat (how it is loaded was shortly mentioned in the previous article):

The ‘.window’ style class is quite simple. It just declares the position and size and whether the window is resizable and modal.

The ‘.content’ style class is a little more complex. It declares the layout and border of the window’s content, which are both instances in AsWing.

A bean (instance) can be declared with a namespace to specify the package (optional) and a class name followed by left and right parenthesis: aw|SoftBoxLayout(…). Between the parenthesis are either constructor argument or property definitions separated by commas: aw|Insets(5, 5, 5, 5) or aw|SoftBoxLayout(axis=v[org.aswing.SoftBoxLayout.Y_AXIS], gap=5) respectively. Constructor argument definitions are simple values; property definitions consist of the property name followed by ‘=’ and the property value.

As you can see in the property definition example, it is also possible to retrieve constants: v[org.aswing.SoftBoxLayout.Y_AXIS]

Applications mostly have multiple screens and windows. Defining all these in a single file would be unmaintainable. Every screen and window is normally defined in its own file. For example the error window is needed by the chat screen to show errors to the users. The chat screen can import the error window as follows:

Declare a namespace for importing external definitions: xmlns=”*.xml”
Declare an imported bean as any other bean with the import namespace and the file name, and the class of the context which shall manage the imported bean: <ErrorWindow id=”errorWindow” class=”org.as2lib.context.support.AsWingApplicationContext”/>
You can give the imported bean an ‘id’ to reference it: <errorWindow>r{errorWindow}</errorWindow>
You may also declare properties for the imported bean: <Chat width=”800″ height=”600″ visible=”true” …/>

The use cases explained above are the most common ones; they probably fit 90% of all needs. I’m going to explain more special use cases in the next article.

Download the As2lib Chat sample application with all needed libraries: As2lib Chat

After taking a closer look at dependency injection and discussing some theory about inversion of control containers in the previous articles, we are now going to examine the As2lib Inversion of Control Container which is largely inspired by the Spring Framework.

Note that I use the name bean to refer to application objects managed by bean factories (they may be defined by a bean definition and may provide setters and getters to access properties).

Bean Wrapper (org.as2lib.bean.BeanWrapper): Bean wrappers are used by bean factories to access properties on beans. They provide methods to check whether properties with a given name are readable and/or writable, to set property values or to get property values and to convert property values to required types.

Bean Factory (org.as2lib.bean.factory.BeanFactory): The bean factory is a central registry for application objects. It holds bean definitions identified by unique names. If a bean is requested the bean factory will either create a new bean on each request with the information provided by the bean definition (prototype beans) or create the bean once and return always the same shared bean (singleton beans). The bean factory invokes lifecycle callbacks on a bean during its creation and destruction; creation involves instantiating the bean, populating it (setting property values) and resolving bean references. Most bean factories also support bean post-processors which can modify new beans before they are returned.

Factory Bean (org.as2lib.bean.factory.FactoryBean): Factory beans can be used as any other bean in a bean factory; but the bean returned by a bean factory on a bean request is not the factory bean itself, but the bean it creates. This mechanism can be used to retrieve constants that shall be used as property values or to create typed proxies for remoting or web services.

Runtime Bean Reference (org.as2lib.bean.factory.config.RuntimeBeanReference): Placeholder holding information to resolve bean references at run-time (dependency injection).

Bean Definition Parser (org.as2lib.bean.factory.parser.BeanDefinitionParser): Parses bean definitions which may for example be described with a XML dialect.

Application Context (org.as2lib.context.ApplicationContext): Application contexts build on the functionalities provided by bean factories and add some new ones that are typically needed by applications. These additional functionalities are: message sources for internationalization, application events, aspect oriented programming support and process support to execute asynchronous processes on start-up.

Let’s take a look at the applicationContext.xml file of the As2lib Chat sample.

Beans are defined with bean elements. Every bean element must at least provide the information needed to instantiate it. This is in the simplest case just a bean class. Properties are defined with property elements. They have a name attribute and optionally a type attribute to convert the property value to. The definition of the message source bean can be interpreted as (the depends-on attribute forces the locale manager to be instantiated prior to the message source):

The instantiation can also be done by a per-class or per-instance factory method. This approach is used by the locale manager whose declaration can be interpreted as:

While beans can be defined with bean and property elements, such a notation is too verbose and inconvenient to use for defining whole user interfaces. There is thus also another XML dialect which you can see a glimpse of in the above example: The definition of the login and chat beans. We’ll take a closer look at this more convenient dialect in the next article. Let’s now think about what the beans are doing.

The message source loads properties files for the target locale with the base name “messages” on start-up: messages_de.properties, messages_en.properties, … . After the properties files have been loaded, the message source can be used to get internationalized messages by name (”title.welcome”, “button.submit”, … ).

The locale manager defines a default locale and a list of available locales. If the language of the operating system does not match one of the available locales, the default locale will be used as target locale, whose properties file is loaded by the message source.

The unnamed style sheet configurer loads the cascading style sheet style.css to format the user interface with.

The smart fox client is used to log-in, create rooms and send messages.

The two beans login and chat are user interface screens. Their definition is done in separate xml files: Login.xml and Chat.xml respectively; these files are loaded and parsed on start-up.

We now know what the bean definitions mean, but how can the application be started? The main.Mtasc class is responsible for starting the application in the As2lib Chat sample. It first specifies the parser to use, then creates a new loading application context with the parser and a bean definition URI, adds a listener to the application context to be notified if the application context has finished loading and at the end starts the loading process.

As soon as the application context has finished loading and parsing the Mtasc class gets the login screen from the application context and shows it.

The last question that remains is: How do we get the needed classes into the swf? This is actually quite problematic in Flash; every needed class must be referenced for example in the first frame which is quite inconvenient. When you are free to compile your application with MTASC things are much more convenient: use Ant build scripts in combination with As2ant to compile the application. With As2ant you have the option to specify the application context as XML source. The SWF task steps through the XML file and compiles all needed classes into the swf.

If you use Eclipse or another development environment with integrated Ant support, compiling everything requires just one click.

Download the As2lib Chat sample application with all needed libraries: As2lib Chat

As already mentioned previously, the XML dialect for user interfaces will be presented in the next article (but you can of course take a look at it in the As2lib Chat sample application if you can’t wait).

An Inversion of Control container is an infrastructural backbone for applications by providing services like lifecycle management, lookup, configuration and dependency resolution.

Lifecycle management: The lifecycle of application objects is managed by the container. The container is able to create new objects, to populate them (applying property values), to invoke initialization and destruction callbacks.

Lookup: References to application objects can be obtained through the container. A container is so to speak a factory.

Configuration: Application objects can be configured in a consistent way (without needing recompilation); for example with an XML dialect.

Dependency resolution: The container should not only configure application objects with simple types, but also manage relationships between them.

While application objects should be able to take advantage of these services, they should NOT depend on the container. This can be achieved by Inversion of Control (and Dependency Injection). Inversion of Control containers are thus also called non-invasive containers.

IoC containers do not impose invasive dependencies on your code, but it is advisable to follow some good coding practices.

* Code to interfaces to maximize pluggability.
* Each application object should have a clear set of responsibilities.
* Favor the Strategy design pattern over inheritance.
* Do not write code to do anything that the container can do.
* Use method prefixes in a consistent manner (Mutator Methods: Naming)

If you follow the preceding recommendations, you can also easily unit test your code and practice test-driven development.

In the next article we are going to take a look at the As2lib IoC container for Flash and its simple XML dialect.

Applications consist of multiple classes which collaborate with each other. For example an instance of class A needs an instance of class B and C to do its job; in other words, class A depends on class B and C; class B and C are thus dependencies of class A.

There are three options to satisfy dependencies:

1. hard-code dependencies,
2. look up dependencies,
3. use the Dependency Injection pattern.

1. Hard-coding dependencies is the easiest strategy: class A simply instantiates its dependencies.

Problems of hard-coding dependencies:

• Configuration is distributed across the whole application (configuration is in this case wiring up the instances and configuring dependent instances).
• Class A must be modified to exchange a dependency (tight coupling): the instance of B may be replaced by an instance of SubB which fulfils the same contract as its super-class B. If B were an interface than any implementations could be used to satisfy the dependency.
• What if a fourth class D has a dependency to the same instance of B as class A?

2. Looking up dependencies requires a context: class A gets the context and looks up its dependencies.

Advantages of looking up dependencies:

• Partially centralized configuration of the context: dependency b is already fully configured; but every instance looks up its dependencies on its own.
• One instance can be used to satisfy multiple dependencies: an instance of class D can simply use context.getB() to get the same instance.

Problems of looking up dependencies:

• Class A depends on a context: makes unit testing more difficult and the look ups are disturbing.
• Code is bloated with dependency look-ups.

3. Using the Dependency Injection pattern is simple and places no requirements: class A provides ways to inject dependencies.

Advantages of dependency injection:

• Configuration is centralized in one place: both configuration of instances and wiring up instances.
• Dependencies can be exchanged easily (loose coupling).
• Wiring up instances is made easy.

Problem of dependency injection: The wiring code may become rather complex if there are a lot of instances with a lot of dependencies to satisfy.

One way to go is to use Constructor Injection. In this approach class A declares a constructor with paramters for both dependencies; the dependencies are given on instantiation.

Advantages of constructor injection:

• Dependencies cannot be changed after instantiation.
• Initialization which requires all dependencies can be done directly in the constructor.
• Instance is not in illegal state after instantiation.

Problems of constructor injection:

• Parameter list of constructor may become very long (there may be a lot of dependencies, plus other information to pass to the constructor).
• Parameters are distinguished by index and not by name, which may make the code harder to understand.

Another way to go is Setter Injection. In this approach class A provides setters for both dependencies; the dependencies are satisfied after instantiation.

Advantages of setter injection:

• Constructor can be used to pass other information than dependencies.
• Code is easier to understand because names rather than indices are used to distinguish dependencies.

Problems of setter injection:

• Dependencies may not have been satisfied when needed.
• Dependencies may be changed after ‘official’ initialization.
• Initialization may have to be done after all dependencies are satisfied: init-method is needed.

While dependency injection is a pattern with many advantages, there are also some problems when used extensively, which can only be solved by an Inversion of Control Container. Such a container provides means of managing instances: lifecycle management (instantiating classes, setting dependencies, invoking init-methods, destroying classes), looking up managed instances, configuring managed instances, resolving dependencies.

In my following articles I’m going to present the As2lib Inversion of Control Container and show you how it solves the problems mentioned above and which other functionalities it provides (for example using its generic XML dialect to create UIs with ActionStep, AsWing, EnFlash or any other component library).

Further Reading: Inversion of Control Containers and the Dependency Injection pattern