Need Help?

Icon

For technical questions, feel free to ask on the Swiz mailing list.

Save as HTML or PDF

Icon

You can export this entire Wiki in HTML or PDF format.

Skip to end of metadata
Go to start of metadata

Page Contents:

Configuration Overview

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. However, in most cases, the default values should work fine (see the note below on Configuration Defaults).


Configuration Defaults

Icon

Unless you are specifying your own set up and tear down values, the only configuration values that commonly need to be set are eventPackages and viewPackages. If you are using Swiz's support for server communication, you may also set defaultFaultHandler.

Specifying Packages

Icon

Note that due to limitations in the AS3 reflection API, when you define eventPackages, you must specify each package individually. Children of your specified packages cannot be resolved and must be explicitly set. This limitation does not apply to viewPackages because they are handled differently, but for consistency it may be useful to use the same rules to define both sets of packages.

Logging

As you can see above, Swiz includes a basic logging target called SwizTraceTarget to trace debugging information to the console. Due to the way the MXMLC compiler works, it was not possible to use the built-in Flex logging target(s), because it increases the size of the Swiz swc by an unacceptable amount. If necessary, you can extend the AbstractSwizLoggingTarget to customize the output.

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 event handlers, 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.

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 event handlers, etc. The default is a capture phase listener for the Event.REMOVED_FROM_STAGE event, with a priority of 50.

Default Dispatcher

The default dispatcher value is "global". This means that in the case where a Swiz instance is the child of another Swiz instance, the child will use the parent dispatcher. This allows for easy communication between Swiz instances, since they all share the same event dispatcher. However, if you want to force a child Swiz to use it's own dispatcher, you can set this value to "local". In most cases, developers should not need to change the default value ("global"). More information on parent-child Swiz instances can be found in the section on Module support.

  • No labels

9 Comments

  1. Anonymous

    It would be nice to know specific cases on which to use and set this properties...

    1. Basically, unless you have some very specific reason to do so, you shouldn't ever need to worry about altering the default values for any of the set up or tear down properties.

  2. Anonymous

    What does 

    defaultDispatcher="global"

    mean?

    What other options are there?

    1. I've updated the page to add a short explanation of the defaultDispatcher property.

  3. Hi,

    I'm using Swiz-1.2 and when I try to use <swiz:config> I get: Could not resolve <swiz:config> to a component implementation.

    Does this mean it has become obsolete or am I blindly missing the obvious?

    Thanks.

    1. If you have a question I'd ask on the mailing list rather than here in the wiki comments. But no, you must be doing something incorrectly, because config is still a public property of Swiz. So the code snippet shown above in the docs is correct.

      1. Sorry ..

        Moving this question to the mailing list.

  4. Anonymous

    Maybe i get this from the wrong side, but is it possible, to add initialization priority to the beans? My problem is the following, i have a service, which would like to call a remote object (which remote object is defined in a beanprovider) but i can't access it, since it hasn't been initialized.

    Probably there is a really easy solution, but until now i was not able to figure it out... should i use events?   

    1. No, there is no priority to Beans, nor should there be. If you'd like to expand on this, please post to the mailing list.