foomonger's blog

Swiz 1.0.0 RC1 was recently released so I've updated my custom metadata processors to work with it. Head over to Google Code to check out [MediateSignal] and [Resource]. Happy coding...

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!

Joel Hooks created this RobotLegs/Signals demo. Ben Clinkinbeard then created this Swiz-version of Joel's demo. I then took Ben's demo and Swiz-ified it even more by using a custom [MediateSignal] processor. Here's the source.

[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.