1. by @nsdevaraj

2. What we'll discuss
DI/ IoC Introduction
View Patterns
What, Why, How
What is Swiz?
Why should you use it?
Advanced Swiz
Swiz DAO

3. What the Hell is IoC?
Inversion of Control, is... design in which the
flow of control of a system is inverted...
-Wikipedia
Separate configuration from
execution
Promotes encapsulation
Promotes simpler, focused
components

4. What the Hell is IoC?
Reusing your code in efficient way.
Consider CRUD Operations Logic
or any logic being written once and
used across your application.
Coding Logic not being repeated
will help you in efficient testing.
Dependency Injection helps you
[Inject] Objects and get use of
deferred instantiation.
Context helps you have a hold on
whole application.

5. IoC / Dependency Injection
The Inversion of Control (IoC) and
Dependency Injection (DI) patterns are all
about removing dependencies from your
code.
IoC/DI are not technologies, they are
methods.
The Hollywood principle "Don't call us, we'll
call you".

6. IoC / Dependency Injection
For example:
public class TextEditor
{
private SpellChecker checker;
public function TextEditor()
{
checker = new SpellChecker();
}
}
What we've done here is create a dependency
between the TextEditor and the SpellChecker.

7. IoC / Dependency Injection
In an IoC scenario we would instead do
something like this:
public class TextEditor
{
private ISpellChecker checker;
public function TextEditor(ISpellChecker checker)
{
this.checker = checker;
}
}
Now, while creating the TextEditor class you
have the control over which SpellChecker
implementation to use. We're injecting the
TextEditor with the dependency.

8. View Patterns Hierarchy

9. MVP Patterns
Passive View Supervising Controller
Both variants allow you to increase the testability of your
presentation logic.

10. MVP Patterns
Passive View

11. MVP Patterns
Supervising Controller

12. Presentation Model

13. Why not Traditional MVC?
You want to maximize the code that can be
tested with automation. (Views are hard to
test.)
You want to share code between pages that
require the same behavior.
You want to separate business logic from UI
logic to make the code easier to understand
and maintain.

14. Comparison
L - UI logic
S - State of the UI

15. Why Passive View?
Presentation Model and Supervising
Controller are both reasonable alternatives.
The strength that Passive View is that both
of the alternatives require the view to do
some of the synchronization work, which
results in more untestable behavior.
In Passive View, all the view update logic is
placed in the presenter.

16. How to create Passive View?
Separate the responsibilities for the visual
display and the event handling behavior into
different classes named, respectively,
the view and the presenter.
The view class manages the controls on the
page.
The presenter contains the logic to respond
to the events, update the model (business
logic and data of the application) and, in turn,
manipulate the state of the view.

17. Swiz Framework

18. What Swiz Users are saying..
“Broadchoice evaluated a few
frameworks and settled on Swiz as the
keystone behind our Workspace
product.”
Sean Corfield, CTO Railo US

19. What Swiz Users are saying..
“Personally I think it is way better then
Cairngorm!”
Kurt Wiersma, some Mach-ii dude

20. Why Swiz?
Because those guys told you to?
Not at all!! But Swiz is...
Simple and effective!
Easy to learn!
Designed to help you write less code!
Encourages loose coupling through
MVC!

21. Let's Start..
What is Swiz all about?

22. Swiz Overview
Flex Applications Require:
Remote Services
Models / Data
Controllers / Logic
Views

23. Swiz Overview
Components need
each other
Wire ourselves
Use Locators
Verbose XML

24. Swiz Overview
Components need
each other
Wire ourselves
Use Locators
Verbose XML
IoC
Annotations

25. Swiz Overview
Views communicate
with components
Flex Events
MVC Paradigm
DynamicMediator
makes it easy!

26. Swiz Overview
Applications need remote data
Async Tokens
Responders
State around calls
SwizResponder
makes it easy!

27. Swiz Features
IoC
injects app
DynamicResponder
remote data
DynamicMediator
event handling
and a whole lot more...

28. Swiz Doesn't mess with..
Excessive JEE patterns
Boilerplate code
Verbose XML / MXML configuration
Overly Prescriptive workflow

29. IoC Recap..
Components require ‘dependencies’
to function
Dependencies may be simple strings and
values, or other components
Resolving complex dependencies is
outside the scope of primary logic

30. IoC with Swiz
Express dependencies through
Metadata, or ‘Annotations’
Swiz takes care of configuration through
Dependency Injection
Views also have dependencies such as
Models, or PresentationModels
Swiz handles everything for you!!

31. Advanced Swiz
Working with Swiz

32. Defining Beans
Define components in BeanLoaders
Written in plain old MXML
Swiz calls objects Beans because it only
cares about their properties

33. Defining BeanLoaders
<BeanLoader xmlns=“org.swizframework.util.*”
xmlns:mx=http://www.adobe.com/2006/mxml>
<mx:RemoteObject id=“userService”
destination=“userService”/>
<mx:RemoteObject id=“mapService”
destination=“mapService”/>
<controller:UserController id=“userController”/>
<controller:MapController id=“mapController”/>
</BeanLoader>

34. Swiz's IoC Factory
When Swiz loads beans, it searches for
‘Inject’ metadata
When objects are retrieved, Swiz
performs the magic of Injecting
Swiz adds event listeners for added to
stage and removed from stage events
Allows Swiz to Inject and clean up Views
too!

35. Loading Swiz
Use Swiz’s ConfigBean in MXML
Requires an array of BeanLoaders
Access to all configuration parameters
<swizframework:SwizConfig strict="true"
beanLoaders="{[Beans]}"
logEventLevel="{LogEventLevel.WARN}"/>

36. Expressing Dependencies
Dependencies are NOT defined in
MXML!
Use [Inject] in your AS objects
Similar to new Spring 2.0 configuration
Qualify bean to inject by id.
[Inject(bean="userController")]
public var userController: UserController;

37. Expressing Dependencies
To inject by type, forget the ‘bean’
Swiz looks for bean which matches the
variable type
Works with interfaces and inheritance
Swiz throws ‘AmbiguousBean’ error if
more than one bean could be injected

38. View Autowiring
You can use Inject on accessors as well
as properties
Properties can be autowired with two
way bindings!
Accessors allow views to perform logic
when dependencies are set

39. Working with RemoteObjects
ServiceHelper bind result and fault
handlers transparently
Swiz offers simple methods for creating
in AbstractController

40. Dynamic Mediators
Add [Mediate] annotation to a Controller
function
[Mediate(event=“eventType”, properties=“foo, bar”)]
public function doStuff(argA : String, argB : String) {}
Swiz creates a DynamicMediator for you
Adds an eventListener for supplied type to
Swiz’s centralDispatcher
Uses ‘properties’ to construct method call

41. Recap
Swiz’s IoC is very easy to use
Swiz provides a simple MVC paradigm
Very little XML! Mostly Annotations
Swiz provides core utilities for:
SwizResponders and ChainEvents
Event handling
DynamicMediators

42. Recap
Swiz represents best practices learned
from years of consulting
Swiz is damn easy!
New features are coming fast and
furious!

43. Swiz 1.0
Module support
Any AS3 Project Support
AIR windows support
Additional metadata:
[PostConstruct], [PreDestroy]
Custom metadata processors (might be
THE killer feature of Swiz)

44. Let's Start Coding...

45. Resources
Swiz Resources
http://github.com/swiz/swiz-framework/
http://groups.google.com/group/swiz-framework
http://cdscott.blogspot.com
http://soenkerohde.com
http://www.returnundefined.com
Other Resources
http://github.com/nsdevaraj/SwizDAO
http://code.google.com/p/dphibernate
http://code.google.com/p/flex-mojos
http://code.google.com/p/loom