Release Notes
v1.4.0 Release Notes
- Added RSL versions of the swcs - These can be found in the rsl folder within the distribution zip file.
- Added covariant view mediation - Allows matching against view supertypes and interfaces in [ViewAdded] and [ViewRemoved].
- Fixed issue with Flex 3 version - Swiz should once again work correctly in Flex 3 projects, and the file size of the Flex 3 swc has been reduced by 50%.
- Fixed minor issue with SharedObjectBean - You no longer need to manually call invalidate() if no local path or name is set.
- Fixed minor issue with Swiz instance tear down after using REMOVE_BEAN
For a complete list of changes made for this release see this compare view.
v1.3.1 Release Notes
- Fixed [ViewNavigator] metadata missing from swc - The new [ViewNavigator] metadata tag was missing from the library's
-keep-as3-metadata
. This has been added.
v1.3.0 Release Notes
- Fixed namespace prefix for MXML declarations - Added design.xml and cleaned up manifest.xml to ensure newer versions of Flash Builder create the swiz namespace prefix correctly.
- Enabled binding to deeply nested bean properties - The [Inject] tag now supports binding to nested properties using syntax like [Inject( "myModel.someObject.someProperty", bind="true" )]. It is the developer's responsibility to ensure that the chain of properties is in fact bindable.
- Added support for nested properties in [EventHandler]'s properties attribute - You can now have Swiz pass nested properties into a method decorated with [EventHandler]. Syntax uses dot notation as expected.
- Added new [ViewNavigator] tag - In Flex mobile projects, you can now use the [ViewNavigator] tag to get a reference to the ViewNavigator instance in non-view classes. Note this is not guaranteed to be populated by the time [PostConstruct] methods run.
- Various bug fixes and improvements - CommandMap, module teardown and other aspects have all been improved.
For a complete list of changes made for this release see this compare view.
v1.2.0 Release Notes
- Mobile, Spark only and Flex 3 support - After sorting out some issues with which SDKs support which versions of modules, we have a new set of SWCs. The primary SWC, swiz-framework-{VERSION_NUMBER}.swc, is intended for use in Flex 4 (or plain AS3 using mxmlc 4+) and beyond, including mobile projects. swiz-framework-{VERSION_NUMBER}-flex3.swc is for use with Flex 3 (or plain AS3 projects compiled with mxmlc 3). The need to produce multiple SWCs is unfortunate, and is caused by the fact that Adobe botched the compatibility interface intended to bridge the gap between Flex 3 modules and Flex 4 modules. If you'd like them to fix this, please vote for this bug. https://bugs.adobe.com/jira/browse/SDK-29336
- [ViewAdded] and [ViewRemoved] - Support for these tags has been added as an official and more performant way to implement the view mediator pattern. They can be added to properties, setters or methods in beans, and Swiz will pass in any instances of the type specified that it detects have been added to or removed from stage. The events that trigger these actions are those specified in your SwizConfig's setUpEventType and tearDownEventType properties. Note that the existence of these tags in a Prototype bean will not trigger the creation of that bean just because a matching view is added/removed. The bean instance containing these tags must already exist when the view event occurs.
- Bug fixes - SWIZ-55, a regression introduced in the v1.1.0 release was fixed, allowing the tear down of non-singleton Prototype beans, and SWIZ-56 (compile error in 4.5 SDK projects due to the MX Module class not implementing IModule, see Flex SDK bug referenced above).
- Build script tweak - The build script has been updated to compile against the Flex SDK specified in build.properties by default. If you are compiling Swiz yourself and want to compile against the SDK specified in your FLEX_HOME environment variable, simply uncomment the appropriate line in build.xml.
For a complete list of changes made for this release see this compare view.
v1.1.0 Release Notes
- Mobile support - Now also producing a SWC for use in Flex mobile projects! It's the same Swiz you know and love, we've just removed any references to Module, since it doesn't exist in the mobile SDK.
- Bug fixes - SWIZ-39, SWIZ-46, SWIZ-47, SWIZ-50 and SWIZ-53, as well as various unreported bugs were fixed.
- CommandMap improvement - Multiple commands can now be mapped to a single event type.
- Metadata auto completion - Added a metadata.xml file for Flash Builder 4.5's metadata auto completion feature.
- Various improvements - API refinement, code cleanup and other minor improvements.
For a complete list of changes made for this release see this compare view.
v1.0.0 Release Notes
- [Mediate] is now [EventHandler] - To better communicate the intention of the tag and in an effort to standardize AS3 DI metadata, [Mediate] has been deprecated in favor of [EventHandler]. The syntax and supported attributes are identical, and [Mediate] is still supported for backwards compatibility, but [EventHandler] is now preferred. Spring ActionScript has always used [EventHandler] for this purpose.
- Smart view tear down - Some actions in an application, like state changes or a container's addition or removal of scrollbars, can cause a view to be temporarily removed from the display list. Swiz now waits a single frame before tearing down views to avoid incidental tear downs caused by the events described previously.
- ISetUpValidator and ITearDownValidator - These interfaces declare allowSetUp():Boolean and allowTearDown():Boolean methods, respectively. Implementing one or both will allow your class to opt out of the automatic set up and/or tear down (by returning false) that is configured for the rest of your application. If you want to opt back in, simply have your class return true for the appropriate method.
- Implicit helper class injections - If an [Inject] tag is declared requesting an IServiceHelper, ServiceHelper, IURLRequestHelper, URLRequestHelper, or MockDelegateHelper by type, Swiz will automatically create beans for the helper classes. As a user you do not need to declare the helper classes as beans.
- ServiceHelper::executeServiceCall() now returns the AsyncToken - Behind the scenes, executeServiceCall() creates and uses an instance of AsyncToken to wire up your result and fault handlers. This AsyncToken is now returned from the method in order to allow additional usage as needed.
- URLRequestHelper::executeURLRequest() now returns the URLLoader it creates - Similar to the executeServiceCall() change, Swiz now returns the URLLoader instance it uses in case you need to interact with it.
- URLRequestHelper now supports extra handlerArgs - All handler methods specified will receive the same handlerArgs provided to executeURLRequest().
- BeanEvent refinements - BeanEvent now has four distinct types: ADD_BEAN, REMOVE_BEAN, SET_UP_BEAN and TEAR_DOWN_BEAN. ADD_BEAN will not only set up the attached object (as SET_UP_BEAN does), it will also make it available as a bean to be injected elsewhere. REMOVE_BEAN is the corresponding type, causing the attached object to be both torn down and removed from the list of available beans.
- Smarter [EventHandler] - The Flash Player's event listening system is, at its core, based on strings. This means that event listeners can sometimes collide if the event types they are listening for have the same string value. However, if you use the class based syntax for [EventHandler] (or [Mediate]), Swiz will now prevent these collisions. So if you have [EventHandler( "FooEvent.FOO" )] on one method and [EventHandler( "BarEvent.FOO" )] on another, Swiz will call the correct one based on the actual type of the event instance, even if both evaluate to "foo". Sweet!
- Better workflow for overriding processors - Needing to override the default processors for tags like [Inject], [PostConstruct] and the others is extremely rare. At the same time, we weren't happy with the cumbersome workflow for doing so. The process has been improved to simply use processor priorities as a unique list. If you provide a custom processor whose priority matches a built-in processor's, Swiz will replace the built-in processor with your own.
- Chaining API enhancements - This is perhaps the most significant and exciting change since the RC2 release. See the wiki for more info. http://swizframework.jira.com/wiki/display/SWIZ/Chaining+API
- Miscellaneous optimizations and bug fixes - There have also been countless refinements, optimizations and bug fixes in order to ensure this is a fast, solid framework. Check it out and let us know what you think!
For a complete list of changes made for this release see this compare view.
v1.0.0-RC2 Release Notes
- Automatic Swiz tear down - When the dispatcher for a Swiz instance is torn down, the Swiz instance itself will automatically be torn down as well, performing all necessary cleanup for the objects it manages. Practically speaking, this means that when you define a Swiz instance within a module or child view, simply removing it from the display list will cause Swiz to clean up the instance for you.
- Performance and Memory improvements - We made it so Swiz's reflection system only captures and stores the metadata references it cares about. In many cases this has the effect of reducing the memory footprint of the reflection system by as much as 90%!
- IServiceHelper and IURLRequestHelper - We took some good advice from the community and created IServiceHelper and IURLRequestHelper interfaces. Aside from just being good form, this will increase the testability of classes that use these helpers by allowing stub implementations to be provided under test.
- ServiceHelper improvements - We also improved ServiceHelper by extending the ability to have extra arguments passed to your handler to include fault handlers. Result handlers have always had this ability and it can be extremely useful. Just like with result handlers, Swiz detects this automatically based on your method signature. Lastly, ServiceHelper::executeServiceCall() now returns the ASyncToken that is passed into the method.
- Chaining API refinements - The Chaining API has been cleaned up to be more consistent and better support chain nesting. This is a very powerful API with near limitless possibilities. For a great (brief) introduction, see http://www.riaspace.com/2010/08/swiz-1-0-chaining-api-explained/
- Miscellaneous bug fixes - We fixed some minor issues with the tear down of pop ups and two way bindings, as well as other small improvements.
- Metadata processor ordering - Metadata processors (both built-in and custom) are now sorted in descending order by their priority to more closely match the way event listener priorities work. We also tweaked the order of our built-in processors so that PreDestroy methods will actually run before an object's injections have been cleared.
- CommandMap - Swiz now provides official, built-in support for the Command pattern! CommandMap is a new class that can be extended and dropped right into a BeanProvider. From the commit message: "Added CommandMap functionality to ease migration from frameworks like Cairngorm, and to accommodate developers/teams that may prefer the Command pattern. Our implementation borrows heavily from Robotlegs (robotlegs.org), because their implementation was clean and in line with our goals." Look for a blog post soon showing how to use this new feature!
- IBeanFactory cleaned up - BeanFactory is really the heart of Swiz. It is responsible for boot strapping Swiz instances and generally managing the IoC container. We have cleaned up its IBeanFactory interface to be more consistent and predictable.
- BeanEvent additions - Related to the IBeanFactory upgrades, we have improved BeanEvent as well. BeanEvent has been around for a while, with constants for SET_UP_BEAN and REMOVE_BEAN. Dispatching a BeanEvent with one of these types and an object instance attached would, respectively, set up (provide the dependencies and process the metadata declared by the object) or tear down (clear out the injected dependencies) the object. Part of the IBeanFactory improvements, however, were the distinctions between bean set up and tear down, and bean addition and removal. Adding a bean makes it available for injection into other objects, removing it makes it unavailable for injection. In order to allow all of these actions to be triggered by an event, we've added ADD_BEAN and REMOVE_BEAN to BeanEvent. One last note is that adding a bean will also set up that bean, but the opposite is not true; you can set up an object without making it available for others to inject. On the other end of the lifecycle, removing a bean will always tear the bean down, but tearing down does not imply removal. Among other reasons, this is because views may be removed from the stage and re-added, causing them to be torn down and then set up again.
For a complete list of changes made for this release see this compare view.
v1.0.0-RC1 Release Notes
- [Dispatcher], IDispatcherAware - You get a reference to the Swiz dispatcher either by decorating a property of type IEventDispatcher with [Dispatcher] or by implementing the IDispatcherAware interface. When using [Dispatcher] you can provide a scope attribute and give it a value of either "global" or "local". Global is the default and will provide you the shared dispatcher from the root Swiz instance. Local will give you the shared dispatcher from the Swiz instance that directly contains your object. Using the local dispatcher allows you to confine events to a child Swiz instance, such as within a module.
- scope attribute on [Mediate] - Directly corresponds to the dispatchers discussed in the point above. This allows you to mediate events dispatched either by the local shared dispatcher or by the root dispatcher.
- SourceMate config file - SourceMate is a great plug-in for FlashBuilder, and one of its features is metadata code completion. We have provided a config file you can import to automatically get this feature for all supported Swiz tags. It can be found at http://github.com/swiz/swiz-framework/blob/master/misc/SwizMetadataSourceMateConfig.xml
- injectionEvent -> setUpEventType, etc. - The event handlers that Swiz uses to set up and tear down your views is now completely configurable. setUpEventType, setUpEventPhase, setUpEventPriority, tearDownEventType, tearDownEventPhase and tearDownEventPriority directly correspond to the values used in the listener creation by Swiz.
- [PreDestroy] and IDisposable - You can use these to define code that should be run when tearing down your views such as cleaning up listeners or setting references to null. Note that this is called in response to the event specified by tearDownEventType, so when using the default of removedFromStage, your view will already be off of the display list by the time these methods are called.
- IInitializing.init -> IInitializing.afterPropertiesSet() - To avoid conflict with UIComponent's method of the same name and to stay more consistent with Spring, the init() method of IInitializing has been changed to afterPropertiesSet().
- Ant build - Full Ant build support!
- Custom namespaces - This is pretty sweet. Swiz can now address code defined in custom namespaces automatically. If you cringe at having to make properties and methods public this feature is for you. Note that due to Flash Player restrictions we still cannot reach protected or private members, but we feel this is a really good compromise. Also note that Flex is not able to bind to non-public members.
- Module and child Swiz support - You can now define child Swiz instances. This is very useful for modules, or potentially even deep dark views that users may never open in your application. When a Swiz instance is created it will dispatch a bubbling event from its host view component that will be caught by a parent Swiz instance further up the display list. A parent/child relationship is then established, allowing the child to inherit beans and configuration settings from its parent.
- AIR window support - Support for separate native windows in AIR has been restored. To make this work you call swizInstance.registerWindow( myNewWindow ) before opening the window via myNewWindow.open(). This will allow Swiz to manage the window and its descendant views, and works by creating a Swiz instance inside the window and making swizInstance its parent.
- View injection changes - Mediate now supports useCapture, which can be useful when using the mediator or passive view pattern. See http://www.webappsolution.com/wordpress/2010/04/20/swiz-10-rc1-removes-autowire-viewtrue-requires-new-abstractviewmediator/ for more info.
- Removed Outject - This turned out to be a bad idea so we yanked it.
- Util classes renamed to helpers - ServiceRequestUtil and URLRequestUtil have been renamed to ServiceHelper and URLRequestHelper, respectively.
- Chain API changes/updates - The chaining API has been cleaned up and made more consistent. IAutonomousChainStep has been added, which is an interface you can use to define steps that can execute themselves. The built in CommandChain and EventChain classes include support for these kinds of steps.
- BeanEvent - BeanEvents can be used to manually control the injection and tear down phases for views and objects you attach to the event. Dispatching BeanEvent.SET_UP_BEAN will trigger Swiz to pass an object through it's injection and mediator processors. Dispatching BeanEvent.TEAR_DOWN_BEAN will trigger Swiz to remove any mediators and injection bindings it has created.
- Removed setUpMarkerFunction - We briefly provided a way for users to determine whether or not a view should be wired up. This has been removed so that a proper, more robust API can be implemented in the future.
- [Inject( bind="false" )] - Previously, when injecting bean properties with a tag like [Inject( "myModel.someProp" )], Swiz would create a binding if the source property was bindable. We have changed the default behavior so to make you choose to create bindings if you need them. To make Swiz to create a binding for you, you must set bind to true in the metadata tag. [Inject( "myModel.someProp", bind="true" )]. In general, using Inject with bindings should be treated carefully. We would like to discourage it's overuse, particularly in situations where users are creating global variables for their applications through the Inject tag.
For a complete list of changes made for this release see this compare view.