Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Navigate space
true
Column
width60%15px
Table of Contents
maxLevel4

Basics

Examples

Best Practices

Further Reading

How It Works

The SwizConfig tag is all you need to configure Swiz. You place this tag in your root Application component to initialize the framework, and it will look something like this:

Code Block

<swizframework:SwizConfig xmlns:swizframework="org.swizframework.*"
	strict="true"
	eventPackages="example.event"
	mediateBubbledEvents="true"
	viewPackages="example.view"
	beanLoaders="{[Beans]}"
	serviceCallFaultHandler="{genericFault}"
	logEventLevel="{LogEventLevel.WARN}"
/>

Let’s break down what each of these properties does:

  • The first two properties, strict and eventPackages are closely related and specify how you wish to handle event types within your application.The strict flag defines which kind of syntax you want to use for your dynamic mediators. If you set the “strict” property to false (the current default), your [Mediate] metadata tags will specify actual event name strings. Using this mode, you could define your mediators like this:
Code Block

[Mediate(event="myFooEvent")]
public function doFoo():...

As you can see, you are defining which event is mediated by its name, not by any sort of constant value. The downside of this approach is that there is no way Swiz can help you by confirming that the event name you’ve specified actually exists in your application. To avoid this, it is recommended that you adopt the alternative approach by setting the “strict” property to “true”.
When “strict” is set to “true”, the event that you specify in your mediate metadata/annotation will be checked at runtime. In order for Swiz to do this, you define the event package(s) you are using, by passing a package or an array of packages into the eventPackages property.
Using the configuration example shown above, where “strict” is set to “true”, and the “eventPackages” have been specified, you can define a dynamic mediator on a method like this:

Code Block

[Mediate(event="FooEvent.FOO")]
public function doFoo():...

In this case Swiz is looking for the class “example.event.FooEvent” because the package “example.event” was specified in the configuration. Swiz will evaluate this properly if it can locate a FooEvent class in one of your eventPackages, and find the constant named “FOO” on that event. Swiz will throw an error if the event class or constant cannot be located. As a helpful extra, if you define an event class name and constant that does not exist in a [Mediate] element, Swiz will generate a stub event class in the debug output when the application runs.

  • If you set mediateBubbledEventsto true you can dispatch an event from any view and Swiz will catch it and invoke all corresponding dynamic mediators. In essence, Swiz will listen for events which bubble up the display list and check to see if you’ve defined any mediated methods for that event type. If it finds one, it automatically re-dispatches that event via its central EventDispatcher to trigger the mediated methods. This means that views don’t need to dispatch events through Swiz, or have any direct coupling to Swiz’s event dispatchment features. The views can dispatch standard events using the built-in dispatchEvent() method that Flex makes available to all DisplayObjects.
  • You should define viewPackages for performance reasons. Every time a view from a defined view package is created, it will be introspected for [Autowire] and [Mediate] metadata. As with eventPackages, you can define multiple comma separated view packages or also an array like:
    Code Block
    
    viewPackages="{['package1', 'package2']}"
    
    Note that the values you define for eventPackages and viewPackages are only the package path itself. So you want a value like “com.user.view”, but not “com.user.view.*”.
  • You can define a method for serviceCallFaultHandler in your main MXML to have a central place for error handling for all calls that use executeServiceCall(). In the configuration example above, the method genericFault() will run if there are errors in your service calls that have not been handled.
  • Swiz uses the internal Flex logging API and you can define a specific logEventLevel to instruct Swiz about what kind of events you wish to capture in your logger. The default is LogEventLevel.WARN.
Column
width5%
Column
width35%
Page Tree
expandCollapseAlltrue
startDepth2
searchBox

Column
Wiki Markup


You configure each Swiz instance using the SwizConfig class. It allows you to modify common settings, and to provide values that allow your tags and code elsewhere to be more concise. Below is an example with all properties shown. Where applicable, they have been set to their default values.

{html}<script src="http://gist.github.com/370666.js?file=gistfile1.xml"></script>{html}
\\

h4. setUpEventType, setUpEventPhase and setUpEventPriority
These properties configure the listener that Swiz will use to trigger the set up of views (assuming they are eligible) to inject dependencies, create mediators, etc. The default is a capture phase listener (to catch all views regardless of their place in the display list hierarchy) for the {{Event.ADDED_TO_STAGE}} event, with a priority of 50.
\\

h4. tearDownEventType, tearDownEventPhase and tearDownEventPriority
These properties configure the listener that Swiz will use to trigger the tearing down of views to clean up injected dependencies, remove mediators, etc. The default is a capture phase listener for the {{Event.REMOVED_FROM_STAGE}} event, with a priority of 50.

Column
width15%