Wiki Markup |
h4. Manually Creating and Destroying Beans
Swiz provides an event-based mechanism to create or destroy beans. To create a new bean, you can dispatch the {{Page Contents:Manually Creating and Destroying BeansSwiz provides an event-based mechanism to create or destroy beans. To create a new bean, you can dispatch the BeanEvent.SET_UP_BEAN }} or {{BeanEvent.ADD_BEAN }} events:
{html}<script src="http://gist.github.com/396855.js?file=swiz_setupbean.java"></script>{html}
Both {{SET_UP_BEAN}} and {{ADD_BEAN}} will process the target object as a bean. The difference between these events is that ADD_BEAN will also add the bean as a singleton to the {{BeanFactory}} cache, while {{SET_UP_BEAN}} does not add the new bean to the cache.
\\
Similarly, to destroy a bean, you dispach the {{ events: Code Block |
---|
|
[Dispatcher]
public var dispatcher : IEventDispatcher;
private function createNewBean() : void
{
userModel : UserModel = new UserModel();
// Swiz will create a bean for the userModel, and process any metadata in it.
dispatcher.dispatchEvent( new BeanEvent( BeanEvent.SET_UP_BEAN, userModel ) );
}
|
Both SET_UP_BEAN and ADD_BEAN will process the target object as a bean. The difference between these events is that ADD_BEAN will also add the bean as a singleton to the BeanFactory cache, while SET_UP_BEAN does not add the new bean to the cache.
Similarly, to destroy a bean, you dispach the BeanEvent.TEAR_DOWN_BEAN }} or {{BeanEvent.REMOVE_BEAN }} events:
{html}<script src="http://gist.github.com/396855.js?file=swiz_teardownbean.java"></script>{html}
The tear down events mirror the set up events discussed previously: {{TEAR_DOWN_BEAN}} cleans up the target by removing injections, event handlers, etc., while {{REMOVE_BEAN}} cleans up the bean as well as removing it from the singleton cache in the {{BeanFactory}}.
{tip}Since BeanEvent is a bubbling event, you can dispatch it from a view. If you dispatch them from non-view beans, be sure you use an injected dispatcher so that Swiz can handle the event.{tip}
\\
If necessary, you can directly call the {{setUpBean()}} and {{tearDownBean()}} methods on the {{BeanFactory}}. Since these methods both take a {{Bean}} instance as an argument, you can use the {{createBeanForSource()}} method on the {{BeanFactory}} to generate a {{Bean}} instance that you can then pass into the set up and tear down methods. However, in general the event-based approach to creating and tearing down beans should be the preferred approach.
h4. {{\[PostConstruct\]}} and {{\[PreDestroy\]}}
Swiz provides two metadata tags which allow you to trigger methods when any bean is set up or torn down. You can decorate a public method with {{\[PostConstruct\]}} and that method will be invoked by the framework after the bean has been set up, had dependencies injected, and had mediators created. For example:
{html}<script src="http://gist.github.com/396855.js?file=swiz_postconstruct.java"></script>{html}
\\
Similarly, a public method decorated with {{\[PreDestroy\]}} will be called when a bean is destroyed by Swiz. This would happen if a UI component is garbage collected, or a module is unloaded.
{html}<script src="http://gist.github.com/396855.js?file=swiz_predestroy.java"></script>{html}
\\
h4. {{SwizConfig}} Options
Six configuration options are available in the [SwizConfig|Configuration] object to specify how UI components are handled by the framework. These are {{setUpEventType}}, {{setUpEventPhase}}, {{setUpEventPriority}}, and the corresponding {{tearDownEventType}}, {{tearDownEventPhase}}, and {{tearDownEventPriority}}. Normally, you can leave these at their default values. But if you need to, you can modify these to alter how Swiz creates and destroys beans that are UI components.
The default {{setUpEventType}} is "addedToStage". This means that whenever a UI component is added to the stage, Swiz will inspect the component and process any metadata it finds. Any dependency injections and event mediators will happen at this time. As mentioned, you may change this value if "addedToStage" is not ideal for your situation. "creationComplete" is another commonly used {{setUpEventType}}.
{note}Be careful if you use an event type that occurs early in the Flex component life cycle, such as "preinitialize", since child components have not been created yet. Conversely, be aware that the Flex framework may internally trigger the removal and addition of components at unexpected times, such as when scroll bars are added to a resized container. In the unlikely (but possible) event that this causes problems, consider an alternative setUpEventType.{note}
At the other end of the bean life cycle, the default {{tearDownEventType}} is "removedFromStage". This means that when a UI component is removed from the stage, Swiz will perform clean up activities such as removing event mediators.
If you require even more fine-grained control, you can specify alternative values for the phase and priority used for the set up and tear down of beans. Typically, these won't need to be changed, but the options are there in case they are needed.
{tip}You can also use the [{{ISetUpValidator}} and {{ITearDownValidator}} interfaces|Interfaces] with UI components to control whether set up or tear down are allowed.{tip}
\\
h4. Swiz and Flex Life Cycle Steps
The following table shows the steps that Flex and Swiz will go through on application startup:
||Type||Step||
|Flex|Preinitialize event|
|Swiz|{{dispatcher}} set|
|Swiz|Swiz created event|
|Swiz|{{domain}} set|
|Swiz|Global dispatcher set|
|Swiz|Processors initialized|
|Swiz|Bean factory initialized|
|Swiz|{{setUpEvent}} and {{tearDownEvent}} values set from {{SwizConfig}}|
|Swiz|Beans defined in the BeanProvider(s) are processed|
|Swiz|(per bean) {{beanFactory.setUpBean()}}|
|Swiz|(per bean) {{\[Inject\]}} processed|
|Swiz|(per bean) {{\[EventHandler\]}} processed|
|Swiz|(per bean) {{\[Dispatcher\]}} processed|
|Swiz|(per bean) Default custom metadata processed|
|Swiz|(per bean) {{\[PostConstruct\]}} processed|
|Flex|Initialize event|
|Flex|Creation complete event|
|Flex|Added to stage event|
|Flex|Display objects in the display list are processed (see table below)|
|Flex|Update complete event|
|Flex|Application complete event|
\\
The following table shows the steps that Flex and Swiz will go through when a new display object is set up:
||Type||Step||
|Flex|Invalidation|
|Flex|Property bindings|
|Flex|Preinitialize|
|Flex|Create children|
|Flex|Initialize event|
|Flex|Commit properties|
|Flex|Resize|
|Flex|Render|
|Flex|Measure|
|Flex|Set actual size|
|Flex|Update display list|
|Flex|Creation complete event|
|Flex|Added event|
|Flex|Added to stage event|
|Swiz|{{beanFactory.setUpBean()}}|
|Swiz|{{\[Inject\]}} processed|
|Swiz|{{\[EventHandler\]}} processed|
|Swiz|{{\[Dispatcher\]}} processed|
|Swiz|Default custom metadata processed|
|Swiz|{{\[PostConstruct\]}} processed|
|Flex|Update complete event|
\\
The following table shows the steps that Flex and Swiz will go through when a display object is torn down:
||Type||Step||
|Flex|Removed event|
|Flex|Removed from stage event|
|Swiz|{{\[PreDestroy\]}} processed|
|Swiz|{{\[Inject\]}} tear down|
|Swiz|{{\[EventHandler\]}} tear down|
|Swiz|{{\[Dispatcher\]}} tear down|
|Swiz|Default custom metadata tear down|
events: Code Block |
---|
|
private function destroyBean() : void
{
// Swiz will destroy the userModel bean, clean up any injected objects, and delete any injection bindings.
dispatcher.dispatchEvent( new BeanEvent( BeanEvent.TEAR_DOWN_BEAN, userModel ) );
}
|
The tear down events mirror the set up events discussed previously: TEAR_DOWN_BEAN cleans up the target by removing injections, event handlers, etc., while REMOVE_BEAN cleans up the bean as well as removing it from the singleton cache in the BeanFactory . Tip |
---|
Since BeanEvent is a bubbling event, you can dispatch it from a view. If you dispatch them from non-view beans, be sure you use an injected dispatcher so that Swiz can handle the event. |
If necessary, you can directly call the setUpBean() and tearDownBean() methods on the BeanFactory . Since these methods both take a Bean instance as an argument, you can use the createBeanForSource() method on the BeanFactory to generate a Bean instance that you can then pass into the set up and tear down methods. However, in general the event-based approach to creating and tearing down beans should be the preferred approach. [PostConstruct] and [PreDestroy]
Swiz provides two metadata tags which allow you to trigger methods when any bean is set up or torn down. You can decorate a public method with [PostConstruct] and that method will be invoked by the framework after the bean has been set up, had dependencies injected, and had mediators created. For example: Code Block |
---|
|
package org.swizframework.quickswiz.controller
{
import org.swizframework.quickswiz.service.UserService;
public class UserController
{
[Inject]
public var userService : UserService;
[PostConstruct]
/**
* [PostConstruct] methods are invoked after all dependencies are injected.
*/
public function createDefaultUser() : void
{
userService.loadDefaultUser();
}
}
}
|
Similarly, a public method decorated with [PreDestroy] will be called when a bean is destroyed by Swiz. This would happen if a UI component is removed from the stage, or a module is unloaded. Code Block |
---|
|
package org.swizframework.quickswiz.controller
{
import org.swizframework.quickswiz.service.UserService;
public class UserController
{
[Inject]
public var userService : UserService;
[PreDestroy]
/**
* [PreDestroy] methods are invoked when a bean is destroyed.
*/
public function clearPollingTimer() : void
{
userService.stopPolling();
}
}
}
|
SwizConfig Options
Six configuration options are available in the SwizConfig object to specify how UI components are handled by the framework. These are setUpEventType , setUpEventPhase , setUpEventPriority , and the corresponding tearDownEventType , tearDownEventPhase , and tearDownEventPriority . Normally, you can leave these at their default values. But if you need to, you can modify these to alter how Swiz creates and destroys beans that are UI components. The default setUpEventType is "addedToStage". This means that whenever a UI component is added to the stage, Swiz will inspect the component and process any metadata it finds. Any dependency injections and event mediators will happen at this time. As mentioned, you may change this value if "addedToStage" is not ideal for your situation. "creationComplete" is another commonly used setUpEventType . Note |
---|
Be careful if you use an event type that occurs early in the Flex component life cycle, such as "preinitialize", since child components have not been created yet. |
At the other end of the bean life cycle, the default tearDownEventType is "removedFromStage". This means that when a UI component is removed from the stage, Swiz will perform clean up activities such as removing event mediators. If you require even more fine-grained control, you can specify alternative values for the phase and priority used for the set up and tear down of beans. Typically, these won't need to be changed, but the options are there in case they are needed.
Swiz and Flex Life Cycle Steps Note |
---|
Note that the Flex component lifecycle events shown in all of these tables outline the most common order, but that it is not universal. For example, when a Module is loaded, it will dispatch addedToStage before dispatching creationComplete. These inconsistencies are simply how the Flex SDK operates. |
The following table shows the steps that Flex and Swiz will go through on application startup:
Type | Step |
---|
Flex | Preinitialize event | Swiz | dispatcher set
| Swiz | Swiz created event | Swiz | domain set
| Swiz | Global dispatcher set | Swiz | Processors initialized | Swiz | Bean factory initialized | Swiz | setUpEvent and tearDownEvent values set from SwizConfig
| Swiz | Beans defined in the BeanProvider(s) are processed | Swiz | (per bean) beanFactory.setUpBean() | Swiz | (per bean) [Inject] processed | Swiz | (per bean) [EventHandler] processed | Swiz | (per bean) [Dispatcher] processed | Swiz | (per bean) Default custom metadata processed | Swiz | (per bean) [PostConstruct] processed | Flex | Initialize event | Flex | Creation complete event | Flex | Added to stage event | Flex | Display objects in the display list are processed (see table below) | Flex | Application complete event | Flex | Update complete event |
The following table shows the steps that Flex and Swiz will go through when a new display object is set up: Type | Step |
---|
Flex | Invalidation | Flex | Property bindings | Flex | Preinitialize | Flex | Create children | Flex | Initialize event | Flex | Commit properties | Flex | Resize | Flex | Render | Flex | Measure | Flex | Set actual size | Flex | Update display list | Flex | Creation complete event | Flex | Added event | Flex | Added to stage event | Swiz | beanFactory.setUpBean()
| Swiz | [Inject] processed
| Swiz | [EventHandler] processed
| Swiz | [Dispatcher] processed
| Swiz | Default custom metadata processed | Swiz | [PostConstruct] processed
| Swiz | [ViewAdded] processed
| Flex | Update complete event |
The following table shows the steps that Flex and Swiz will go through when a display object is torn down: Type | Step |
---|
Flex | Removed event | Flex | Removed from stage event | Swiz | [PreDestroy] processed
| Swiz | [Inject] tear down
| Swiz | [EventHandler] tear down
| Swiz | [Dispatcher] tear down
| Swiz | Default custom metadata tear down | Swiz | [ViewRemoved] processed
|
|