Swiz Framework

Whew! It’s been a while since the alpha release and have we ever been busy! Due to the monstrous list of changes and improvements you see below, we’re not going to try covering all of them in depth in this post. Many of these features will get posts of their own, so keep an eye out for those coming soon. In the meantime check out the changes, dive into the code or grab the SWC and head over to the list with any questions or comments.

Update: Because I am a bone head, and I was running low on time, there were some potential problems with the initial SWC. The two files below *actually* support pop up injection, and the one whose name implies as much is compiled with the Flex SDK set to external. If you are using Flex I would recommend that one, so you can choose which SDK to build against. If you are using pure AS3 you will need to use the one with the SDK included, as we have not yet completely separated the logging from the Flex framework. Sorry for any inconvenience.

v1.0.0-beta-patched-externalSDK
v1.0.0-beta-patched

Changes and additions in Swiz 1.0.0 Beta:

• SwizConfig
  • SwizConfig is back and better than ever
  • injectionEvent, injectionEventPhase and injectionEventPriority fully customizes the listener that triggers inspection of your views
  • injectionMarkerFunction allows you to specify a decision maker function that determines if a view should be inspected and processed. Easily checked for property existence, interface implementation or any other custom criteria.
  • eventPackages and viewPackages support for .* – we’ve seen people get tripped up by specifying packages with a trailing *, so we added support for it
  • loggingTargets to see what Swiz is doing behind the scenes
• Parent and child Swiz relationships
  • Swiz instances declared on IEventDispatcher instances that are descendents of another Swiz dispatcher become child instances
  • Child instances can use beans declared in parent instances
  • Child instances inherit eventPackages and viewPackages from their parent
  • Parent instances can mediate events dispatched from child instance
• ISwizInterfaces
  • ISwizInterface is the parent interface for a few interfaces beans can implement to have Swiz give them special treatment. Interfaces are fulfilled after all metadata has been processed. The interfaces are as follows:
  • ISwizAware – Implementers will be provided with a reference to their containing Swiz instance.
  • IBeanFactoryAware – Implementers will be provided with a reference to the BeanFactory for their containing Swiz instance.
  • IDispatcherAware – Implementers will be provided with a reference to the event dispatcher used by their containing Swiz instance. Useful for non-display list beans that need to dispatch system events.
  • IInitializing – Implementers will have their init() method called.
• Service utils
  • Consistent with our principle of never making you extend Swiz classes, we’ve moved the functionality previously provided by AbstractController into their own utility classes.
  • executeServiceCall() is now provided by ServiceRequestUtil
  • executeURLRequest() is now provided by URLRequestUtil
  • You can instantiate these classes directly, but the recommended practice is to define them as beans and inject them by type.
  • AbstractController still provides these methods in order to ease migration pains. Convert to the utilities when you’re ready.
• Generic chaining support
  • We have added a fantastic, robust and extensible chaining infrastructure to the framework.
  • Event chains and command chains available “out of the box”
  • Create custom chain types by extending a base class and overriding a single method
• Processor priorities
  • Metadata processor execution is now ordered using a priority property
  • Configure your custom processors to run at any position in the list of default processors
• Ignore metadata starting with _
  • Thanks to some new metadata generated by Flex 4 debug builds, we ignore all metadata tags starting with an underscore
• Support for multiple Mediate tags
  • You can now pile on as many [Mediate] tags as you want to a method, and it will be called in response to all the specified events
• Support for [Mediate( "MyEvent.*" )] syntax
  • To facilitate easy support for front controllers and the command pattern, specify that you want a method to be called in response to all event types matching public static constant values on a given class
  • Currently in raw form, will be refined in future versions
• Support for properties on dynamic events
  • We’ve corrected the logic that runs in response to tags like [Mediate( event="MyEvent.FOO", properties="username, password" )] to allow the use of dynamic event classes
• Storage beans
  • SharedObjectBean and EncryptedLocalStorageBean added to simplify usage of this type of functionality
• [VirtualBean] has been renamed [Outject]
  • Same functionality, new name
• Initialization changes
  • We completely revamped the way Swiz initializes and processes beans
  • Prototype is now correctly implemented offering deferred instantiation and (by default) a fresh copy to each request for its type/name
  • Each bean is fully initialized and processed before being handed back to whoever requested it, providing full support for proper cascading
• [Inject] is the new [Autowire]
  • [Autowire] is still supported, and will continue to be for the foreseeable future, but it has officially been deprecated
  • If you are listening to Swiz’s logging, you will get a warning for each [Autowire] tag instance
  • Injections are now considered required by default. If a dependency is optional, use the following format [Inject( required="false" )]
• Metadata processors API updated
  • Processors that deal with one tag at a time can simply extend BaseMetadataProcessor and override the public function setUpMetadataTag( metadataTag:IMetadataTag, bean:Bean ):void
  • Processors that need to process groups of tags for purposes of ordering or coordination may override public function setUpMetadataTags( metadataTags:Array, bean:Bean ):void
  • Corresponding tearDown methods are provided as well
  • If you prefer not to extend a Swiz class simply implement IMetadataProcessor
• Metadata processors can support multiple tag names
  • metadataNames specifies the tag names a processor will handle. This is how InjectProcessor handles both [Inject] and [Autowire]
• [PostConstruct]
  • We’ve added support for [PostConstruct], which can be used to decorate methods that will be run after all [Inject] tags have been processed.
  • Supports an order attribute for executing multiple methods in a specific sequence
• SwizLogger and loggingTargets
  • Swiz’s internal classes now use the static SwizLogger class to properly log output in a standardized way
  • The loggingTargets property of SwizConfig allows you to specify an array of ILoggingTarget instances, with full support for filtering, message customization, etc
  • Work in progress, logging has not yet been fully implemented across all Swiz classes. Swiz will be *very* chatty before everything is said and done.
• MockDelegateUtil
  • TestUtil has been renamed and reworked into MockDelegateUtil
  • Provides createMockResult( mockData:Object, delay:int = 10 ):AsyncToken and createMockFault( fault:Fault = null, delay:int = 10 ):AsyncToken methods
• AMFUtil
  • Useful for parsing stored AMF3 data, particularly helpful when combined with MockDelegateUtil to create a mock service layer
• Added FlexFormatter prefs to GitHub
• Pop up support
  • Pop up views can now be properly wired
• IBeanProvider.dispatcher implemented
  • BeanProvider and BeanLoader now include a dispatcher property (again) that is the IEventDispatcher used for “system events” in a Swiz instance.
  • Useful for providing non-view classes a way to dispatch events that will be heard by Swiz.
  • Same instance provided to implementers of IDispatcherAware
• Main dispatcher processed as bean
  • The main view/event dispatcher on which Swiz is defined can now be properly wired

Enjoy!