A Flex developer working on a Mac commited a new asset in the assets folder and then referenced it in a MXML file. He compiled the application, tested, then committed the new code on the Perforce system. Soon after, our Hudson instance doing continuous integration on the project reported a build failure on the Flex application. The failure message was huge, as it seemed that the Flex compiler was not able to resolve any of the application assets. The error message was basically a list of assets reported as missing. Here’s an excerpt :


...
[java] D:\hudson_home\jobs\project\workspace\project-client\src\assets\stylesheets\common.css(144): Error: Invalid Embed directive in stylesheet - can't resolve source 'Embed(source = "/assets/chrome/BackgroundChrome.png", scaleGridLeft = "5", scaleGridTop = "5", scaleGridRight = "965", scaleGridBottom = "685")'.
[java] scaleGridLeft="5", scaleGridTop="5", scaleGridRight="965", scaleGridBottom="685");
[java] D:\hudson_home\jobs\project\workspace\project-client\src\assets\stylesheets\common.css(150): Error: Invalid Embed directive in stylesheet - can't resolve source 'Embed(source = "/assets/chrome/BackgroundBorderChrome.png", scaleGridLeft = "5", scaleGridTop = "5", scaleGridRight = "965", scaleGridBottom = "685")'.
[java] scaleGridLeft="5", scaleGridTop="5", scaleGridRight="965", scaleGridBottom="685");
...


It seemed like all of the assets were missing. I quickly checked the Perforce system and all of the assets were there. After taking a good look at the failure message, a specific part caught my attention :


Error: exception during transcoding: Failed to grab pixels for image D:\hudson_home\jobs\project\workspace\project-client\src\assets\icons\profil_icon.png

[java] [Embed(source="/assets/icons/profil_icon.png")]
[java] D:\hudson_home\jobs\project\workspace\project-client\src\com\project\user\presentation\view\renderers\UserListItemRenderer.mxml(16): Error: Unable to transcode /assets/icons/profil_icon.png.
[java] [Embed(source="/assets/icons/profil_icon.png")]


So one of the assets, a PNG file, was generating a different exception than the other resources. As I soon found out from this post, if one [Embed] directive is failing then all of the other [Embed] tags are reported as failing as well. So I just had to find out why the PNG resource was failing.

One thing caught my eye : the PNG file was marked in Perforce as of type Unicode, while the other resources were marked as binary, as it should have been. While this was just fine on Mac machines, on Windows machines this lead to the Flex compiler being unable to transcode the image. So what I had to do is simply change the Perforce filetype of that specific PNG file from Unicode to Binary. After doing this, the Flex compiler managed to finish its job properly and the build succeeded.

As you can see, the architecture is quite simple. We have a layer of service API which is implemented by another layer, a LCDS-based implementation which, in turn, uses an implementation of a DAO layer. In the diagram, I grayed out the DAO layers because they are of no interest to our current subject.
Briefly, the service API only contains the interfaces of the services along with related objects : exceptions and DTOs.

We use our custom business exceptions to signal to service clients any issues encountered during service operations. Each custom exception has a public code which indicates its nature and meaning.

Simple exception mechanism

At first, we decided to simply throw business exceptions from the service implementations. This meant that the Flex client application would receive a fault event, which it had to strip to get to the actual exception.
Here is the Java service exception and method :

public class InvalidCriteriaException extends Exception
{
    ...
    public String getCode()
    {
        return ExceptionCode.INVALID_CRITERIA.toString();
    }
}
 
public SearchResultDto searchById(SearchCriteriaDto criteria) throws InvalidCriteriaException
{
    try {
        // do some processing, use the DAO layer
        ...
    }
    catch (SomeDaoException e)
    {
        // convert the DAO exception into a service exception and then throw the new exception
        ...
    }
    catch (Throwable e)
    {
        // any unexpected exception is caught and a new service exception is created and thrown further
        ...
    }
}

And the corresponding Flex code :

    private function handleException(event:FaultEvent) : void {
        var errorMessage:ErrorMessage = event.message as ErrorMessage;
        Alert.show(errorMessage.rootCause.code);
    }

As you can see, the Java service code is cluttered within a try..catch block, which also contains the details on converting possible exceptions to service exceptions. On top of this, the client-side code is not very clean either, because it uses an untyped object ( rootCause ) on which we make assumptions and assumptions are generally a bad thing to do in your code. The right solution on the client-side would be to take advantage of the properties of the ErrorMessage object.

A better exception mechanism

In order to leverage the properties of the Flex class ErrorMessage, we decided to only throw instances of flex.messaging.MessageException, which is shipped in LCDS (and BlazeDS). To do this in an easy way, we proceeded in making sure that each of our custom exception would inherit MessageException :

public class InvalidCriteriaException extends MessageException
{
    ...
}

The service layer would now throw only MessageException-derived exceptions, which get deserialized on the client-side as instances of ErrorMessage. The Java exception has a field called code, who is translated in the Flex class as the field faultCode. So the only thing left to do is make sure that the code field is set to a proper value on the server side.

Using Spring BlazeDS Integration and a custom exception translator

The solution described in the previous paragraph still comes with some flaws. First of all, we didn’t get rid of the try..catch block in the service code. Uh, ugly.
Second, there is a design issue : the service API layer is exposing the service interfaces along with the exceptions, which are now derived from a LCDS exception. This makes the service API layer dependent on LCDS, which is not what we want. The service API should be clean and free of any implementation-specific dependencies.

These flaws were removed once we switched to using the Spring BlazeDS Integration to expose our Spring-based services as LCDS destinations. Along with other great features, Spring BlazeDS Integration comes with the notion of custom exception translators. The translator makes sure that exceptions thrown from the Spring-exposed LCDS destinations are converted to meaningful exceptions for the client, all of this far away from the service code which will be far more simple and clean.

First of all, we create our own exception translator :

public class ExceptionTranslatorImpl implements ExceptionTranslator
{
    public boolean handles(final Class<?> clazz)
    {
        return Boolean.TRUE;
    }
 
    public MessageException translate(final Throwable throwable)
    {
        final MessageException exception = new MessageException();
        exception.setCode(ExceptionCode.SYSTEM.name());
 
        if (throwable != null)
        {
            if (throwable instanceof BaseCustomException)
            {
                exception.setCode(((BaseCustomException) throwable).getCode().name());
            }
 
            exception.setRootCause(throwable);
            exception.setMessage(throwable.getMessage());
        }
 
        return exception;
    }
}

Then we need to register it in the application context :

  	<bean id="allExceptionTranslator" class="com.adobe.myproject.exception.ExceptionTranslatorImpl" />
 
	 <flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml"  >
        <flex:exception-translator ref="allExceptionTranslator"/>
		<flex:message-service/>
		<flex:secured />
	</flex:message-broker>

We can now remove all the exception conversion logic from the service code and let the exception translator handle all of these ugly details for us. Much better, isn’t it ?

I’ve recently started working on a project with an existing codebase, out of which 90% is Flex code. Facing the possibility of applying our team’s coding guidelines to countless lines of Flex code that I would have to modify, I turned to my browser and began a frantic search for something that would help. I came across a small project aiming to provide exactly what I needed : Flex formatting options. The project is called Flex Formatter and it can be found at  http://sourceforge.net/projects/flexformatter/ on good ol’ Sourceforge. It provides a set of formatting options for ActionScript and MXML code which may cover some of the common needs of any Flex developer out there.

To install it, I downloaded the latest version (0.6.7 at the time of this writing) from Sourceforge, in the form of a jar file. I copied the jar in Eclipse’s plugins folder and restarted Eclipse.

After restarting Eclipse, a new item called Flex Formatting appeared in Eclipse’s Preferences window, with options for ActionScript and MXML indenting and code formatting. I found particularly useful the indentation and the text wrapping options. Once I decided on the rules I wanted, I clicked ‘Apply’ to save my changes. Back in Eclipse’s main toolbar, 2 new buttons have appeared : Format Flex code (selected lines) and Indent Flex code (selected lines). The first will apply the rules you have specified on any Flex code selection (including indentation), while the second button will only properly indent the Flex code selection.

Another interesting option of this small tool is the possibility to export the rules to a file and import them later. This can be done from the same Flex Formatting item in Eclipse’s Preferences window. Exporting & importing make it easier for team members to share their coding style options. One team member could create the rules, export them to a file and put the file on a versioning server. The rest of the team could then retrieve the file from the versioning server and import it in Eclipse.

The formatter is far from complete. In its current version (0.6.7), it lacks some options like performing the formatting on save and it could also do with a more fine-grained set of formatting options. However, after just a couple of days of using it, this tool has saved me a lot of time and energy and I think it is definitely worth using it and I would recommend it to any Flex developer. Just try it, it won’t bite. It just flexes.