foomonger's blog

I started using the SwizLogger recently and quickly realized I wanted to do the following:

1. Create ILogger instances without importing Swiz classes in my application classes
2. Easily add targets in MXML

#1 isn't a huge deal if you consider logging to be more of a system tool than an application dependency, but if I'm avoiding Singletons why not keep it up. #2 also isn't a big deal because it doesn't take much ActionScript to add logging targets, but I think it makes a lot of sense to do it declaratively.

Piotr Walczyszyn created a custom LogProcessor to address #1, but I didn't like how the TraceTarget was hard-coded into it. Instead of building more complex processor I decided to create a bare-bones LoggerProcessor and SwizLoggerConfig class.

Here's an example application's source (the SWF is just a button):  Source

The LoggerProcessor is again bare-bones. All it does is inject an ILogger instance using SwizLogger:

[Logger]
public var logger:ILogger;

The LoggerProcessor priority is set to be one above [Inject] so the injected ILoggers are available at [Inject] and [PostConstruct].

SwizLoggerConfig doesn't do too much either. It's just provides a default public Array property which is used to add targets to the SwizLogger.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:utils="com.foomonger.swizframework.utils.*"
        xmlns:view="example.view.*"
        xmlns:local="*"
        layout="absolute">
    <mx:Script>
        <![CDATA[
            import mx.logging.LogEventLevel;
        ]]>
    </mx:Script>
    <utils:SwizLoggerConfig>
        <mx:TraceTarget
                includeCategory="true"
                includeDate="false"
                includeLevel="true"
                includeTime="true"
                level="{LogEventLevel.INFO}"
                filters="*"
                fieldSeparator=" | "/>
    </utils:SwizLoggerConfig>
    <local:SwizLoggerConfigExampleSwiz/>
    <view:MainView/>
</mx:Application>
 

The value of these classes will depend on your personal style and preference. I wrote them so I like them. They're available on Google Code.

Happy coding.

* Update: Here's the MXML syntax for adding multiple packages to the filters Array:

<mx:TraceTarget
        includeCategory="true"
        includeDate="false"
        includeLevel="true"
        includeTime="true"
        level="{LogEventLevel.INFO}"
        fieldSeparator=" | ">
    <mx:filters>
        ["foo.bar.*", "com.foomonger.*"]
    </mx:filters>
</mx:TraceTarget>
 

I'm using the Swiz Framework in a side project which requires runtime loading of all the copy. I decided to use Flex's ResourceManager by parsing static XML files and populating the ResourceManager with the newly created ResourceBundles. Binding resources into view's wasn't too bad, but it could be better. For one thing any component that needed a resource included a ResourceManager dependency. So I thought about it and then created a ResourceProcessor which really cleans things up.

Here's an example application:

• SWF
• Source

I set up the [Resource] tag to mirror the @Resource directive. All you do is decorate a property like so:

[Resource(key="title", bundle="example")]
[Bindable]
public var title:String;

The processor binds the resources so they will update when binding events fire in the ResourceManager. And you only need to include a ResourceManager dependency if you are adding resources at runtime or changing the locales array.

This processor is available in my foomonger-swizframework project on Google Code. Enjoy!