Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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:

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

[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:
    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.
Navigate space
  • No labels