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 think TDD is great when you know what the code should do. When I'm writing parsing code or something else very utilitarian I definitely prefer to write the tests first. As a Flex/Flash developer, most of my code is directly for the UI, and often I find that I'm not entirely sure what my code should do right away. I'm becoming a big fan of the Presentation Model pattern, but even with that, I find that it takes exploratory development to determine exactly which component should do what and which logic should go where.  I found it very burdensome to update both the regular code and tests step-by-step . Not being a TDD expert I could easily be doing something or interpreting something incorrectly. Or perhaps I'm just lazy.

I've decided, at least when it comes to UI development, to follow a looser Testable-driven development technique. As I'm fleshing out my component logic, I constantly ask myself, "Is this code testable?" or more generally "How will I know if this works?" This primitive technique gives me the freedom to write exploratory code while helping to reign in potential magic logic. I then write tests once things have settled down, refactoring any logic to make things more testable as necessary. This technique also fits my style of coding where I like to sketch out logic with small tracer bullets.  It definitely takes some discipline to think about the testability of the code, but so far I'm much more comfortable with testable-driven development for UI work.