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>
 

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!

[MediateSignal] is the Signal equivalent of [Mediate]. Here's an example:

[MediateSignal("galleryUpdatedSignal")]
public function galleryUpdated(gallery:Gallery):void

[MediateSignal] takes a Signal Bean name or type and adds the decorated method to the Signal (see GalleryThumbnailsPresentationModel for examples).

This is what I changed from Ben's demo:

• Created the MediateSignalProcessor
• Added [MediateSignal] metadata to the Signal listeners
• Made the Signal listeners public
• Named the Signal Beans
• Removed [PostConstruct] methods that added the Signal listeners
• Removed injected Signals that weren't being using to dispatch

[MediateSignal] makes using Signals in Swiz very parallel to using Events (especially if you define the Event dispatcher as a Bean and inject it by name). And just like Events, you only need to [Inject] the Signals into Beans who are dispatching Signals. I was pretty excited to create my first custom processor and play with Signals for the first time. Let me know what you think!

Disclaimer: I set up MediateSignalProcessor to also handle DeluxeSignals and remove listeners, though to be honest I didn't test those.

* Update: I've posted the processor on Google Code and it contains unit tests (including DeluxeSignals and removing listeners).

** Update: I've created a bare-bones example application: SWF and Source.