by Arturo Alvarado

Parsley

Content From the blog

http://artinflex.blogspot.com/2010/09/quick-dive-into-
parsley-parsleys-basic.html

Art's Flex Notes

by Arturo Alvarado

Saturday, September 4, 2010

Quick Dive into Parsley (Intro - Why Parsley? - Part 1)

This is a series of articles that should help you get you up and running with Parsley quickly. It
starts with the basics and moves up to more advanced features. If you are new to Parsley or with
to find out how to use Parsley in and MVC implementation, you came to the right place.

Here is an index of the Parsley posts and examples with source that you will find:
Why we like Parsley: This note.
Parsley Basic Concepts: http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-
parsleys-basic.html
Basic Injection Example: http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-basic-
injection.html
Basic Messaging Example: http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-basic-
messaging.html
Basic Messaging with Flex Events Example: http://artinflex.blogspot.com/2010/09/quick-dive-
into-parsley-messaging-with.html
Nested Contexts & Object lifecycle methods: http://artinflex.blogspot.com/2010/09/quick-
dive-into-parsley-nested-contexts.html
Decoupled Bindings: http://artinflex.blogspot.com/2010/10/quick-dive-into-parsley-
decoupled.html
Dynamic Commands & Dynamic Objects: http://artinflex.blogspot.com/2010/10/quick-dive-
into-parsley-dynamic-command.html
Automatic Component Wiring: http://artinflex.blogspot.com/2010/10/quick-dive-into-parsley-
automatic.html
Fast Inject (Injection without Reflection): http://artinflex.blogspot.com/2010/11/quick-dive-
into-parsley-fast-inject.html
Presentation Model in Parsley (MessageInterceptor):
http://artinflex.blogspot.com/2010/11/presentation-model-implemented-in.html

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

Why Parsley?
A little background on how and why we chose to use Parsley in our projects.

I'm a developer who ran into Flex some years back and fell in love with it. As usual, the quest
for finding better ways of doing things is always on, and as projects grow in size this becomes
even more important. A while back I heard about the MVC Architecture pattern, and in larger
projects this makes sense. In brief, MVC is a software engineering design pattern, that involves
separating the Model, the View, and the Controller, with the goal of being able to develop,
deploy, and test your Components individually (generally called decoupling). You can get a
much more detail explanation of the MVC concept in Wikipedia
(http://en.wikipedia.org/wiki/Model View Controller), but in a very simplified fashion, the View
is the collection of User Interface elements, the Model is the collection of classes that hold and
manipulate your data, and the Controller is the collection of classes that receive input and
proceed to either make calls to Model Classes, or Services to load data into the Model. The idea
of separating all three is actually a good idea, you will be surprised how much time you will save
by doing this as projects grow. The main goal is to decouple your objects. The idea is that every
object should do its own thing, and only its own thing. Decoupled objects benefit from being
more easily reused in other projects or even within the same project because they are not tied to a
specific implementation, also they are more easily tested individually (Unit Testing), since you
(the developer) makes sure that it does what it is supposed to do, regardless of where or how it is
implemented. The drawback of highly decouple applications is that it's a bit harder to follow the
whole application logic, as it's no longer obvious. Simply put; your application becomes more
"event driven" and easily become more asynchronous, which leads to having no control of when
exactly the methods will be called.

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

Now MVC is a pattern, not a framework. There are multiple frameworks that have been
created to help you follow the MVC pattern, and one of the most known in the world of Flex is
called Cairngorm (http://sourceforge.net/adobe/cairngorm/home/). Cairngorm is one of the
original frameworks aimed to assist the developer in following the MVC pattern. You do not
need a specific framework to do so, but they do help. When I started using Cairngorm, I really
enjoyed the benefit of using it as the projects grew in size. Cairngorm is one of the most popular
MVC frameworks for Flex, probably because it is officially back by Adobe, and it's been around
longer.

A lot of people will bash Cairngorm for some of the ways it handles things, particularly for its
implementation of the ModelLocator. Cairngorm uses Singletons, a single instance of a Class
(which could also be called a Global Variable), to hold some of its objects. Regardless of its
"incorrect" way of implementing things, it's actually useful. Cairngorm promotes the use of a
specific structure, which makes team collaboration easier, and as much as people could call its
ModelLocator an atrocity, it's actually handy in many cases.

A simple example: Let's say that you have an application that allows users to Log In. But
being logged in is not a requirement in every area of your application. Once the user has logged
in, you probably want to hold the state that the user is logged in and the session id. Now, you
add some feature that requires the user being logged in, so the component has to check if the user
is logged in before it lets the user access that feature. Using regular dependency injection,
involves passing the logged in status information all over the place, just in case one of the
subcomponents requires access to that information, even if the parent's don't really care. With
Cairngorm's ModelLocator, that's not the case, because if a subcomponent needs the logged in
status, it doesn't need to get it from its parent, it can just reach and grab it. This will uncouple all
the component's that don't need this information from this particular implementation, which is
good, cause you can reused them more easily. They don't need to carry data around that they
don't need, simply because one of their children or grandchildren might need it.
So if this is good, why do people "hate" it so much? Well, the problem is with the "reach and
grab it", particularly with the "reach". Although some decoupling is accomplished using
Cairngorm, the component's that needs to "reach" now gets coupled and tied to that particular
implementation of the ModelLocator, and doing unit testing become much more difficult.

That said, the main reasons we decide to leave Cairngorm follow:

1. Cairngorm is heavily dependent on binding, which is useful in many cases but can get
annoying. Under Cairngorm , the Controller makes a Service call, and feeds the Model
through Commands. But let's say that the user request some data, and when the service
call returns it turns out that there are no records that match that search, so nothing will be
added to the Model. Since the View is bound to the Model, the view will usually refresh
when new data arrives, but if there is no data added, well it won't refresh, there is no
change. It's a nice feature to let the user know that no data was found, but the view will
simply not know this. You could of course create a popup from the Command letting the
user know that that no data was found, or you could set a flag in the model that the View

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

is "watching" to raise the issue and display the message. The popup approach I don't like
because you are moving elements of the View to the Command which breaks the pattern,
but more importantly, still the view doesn't know that there is no more data and can't
adjust because of it. Setting a flag would be the one "correct" approach, but this adds a
lot of logic for a simple thing. Why a lot of logic? Well, first you need to add a property
change watcher (ChangeWatcher.watch()). But property change watchers in Flex lead to
memory leaks if you don't remove them before the item is destroyed
(ChangeWatcher.unwatch()). But Flex doesn't have "Destroyers" that get called before
your object get's destroyed. Since it's a view, you can use the removedFromStage event
that would be called when your item is removed. Great!... Right?... Wrong. See the Flex
framework occasionally re-parents view components (for example when scrollbars are
added) which will trigger the removedFromStage event. So, now you are also force to
monitor the addedToStage event to set the watchers back up in case they got removed
during a re-parenting process. Although this would be a "correct" approach, I simply
think it's way too much of a hassle for something that simple. You could set up an event
listener tied to the Model, but you still need to remove the event listeners when your view
is being removed, same long approach as with the flag, and again you couple your view
even more to that model. I, of course, hacked my way around it, setting a callback
function in the event that triggers the command so that the command can notify the view
directly for things such as this. Some might argue that this breaks the MVC pattern, but
there is no ONE way of implementing MVC, and it certainly accomplishes the
decoupling goal in a much simpler fashion. The only really un-debatable problem with
my quick hack is that only the view that generates the event that called the command will
get the message back from the command.
2. Cairngorm's limited decoupled messaging system. The second really important issue
with Cairngorm from my point of view is somewhat related to issue #1. Cairngorm's
decoupled messaging system is aimed towards executing Commands. All other
messaging is "supposed" to be done through either binding or Flex/Flash Events, and
although binding is messaging, binding is not the best way to accomplish ALL
messaging. Besides, Binding involves coupling, which is the opposite of the original
goal. You can use Flex's event mechanism, but that also means that you will go back to
coupling. Flex's Binding and Event messaging mechanism involves that you must listen
to a specific object. Although Cairngorm's messaging is aimed to aid in some issues, it is
simply too shortsighted, it's basically a one way road.
3. The Singleton. I know I said it comes in handy, but it can become a problem. Since the
Model is a Singleton, it is shared by the whole application. Sometimes you want to have
SubModels. Model's that are shared only in a section (context) of you app. Or you have
an application that allows the user to edit a customer's data, but suddenly the user needs
to edit another customer's data, but the user doesn't don't want to close the window and
"save" the changes to the other customer just yet, just open a new Customer window to
work in. Basically an MDI (Multiple Document Interface) app. You need two models
that are identical, but hold different data views. Cairngorm will not help you here, since
the models are global. They are not within a specific scope. You of course, can find the
way around that, but it's on your own.

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

4. Lack of Modularity. Cairngorm is very friendly with RSL's, but it's not friendly with
Modules. You can use Modules, but it's somewhat limited. This is related somewhat to
issue #3. Since Models and the FrontController are implemented with Singletons. There
is a way to make it work with modules, but keep in mind that is not how it was designed
to work. You can read about it here.

So all that said, I still think Cairngorm will help you with non-small projects, but there are
"better" ways.

So I'll explain what "better" means to us. Ideally it must be:

• Flexible. There is no one absolute unique "right" way of doing things. Patters are good
as long as they help you accomplish your goals. When they start getting in the way, it's
time to chose a different pattern or at least modify it. They guys from the very successful
Flick site have a saying that they "generally try do the dumbest thing that will work
first." Sometimes elegant solutions are not the best way of actually getting things done.
• Have a powerful Decouple Messaging System. Way beyond what Cairngorm does.
Messages should be able to be sent anywhere to anywhere in a decoupled way. A plus is
if the can be limited within a specific context (scope).
• Allow for easily integration with Flex Modules. This is a BIG important issue for us.
• Aid in decoupling. A framework that aids with achieving Inversion Of Control (IOC).
• Simplifies Dependency Injection. You don't need a framework to use Dependency
Injection. Actually DI is available by default in ActionScript, or just about any OO
language. The issue with DI without the assistance of a framework is that you will have
to manually carry all objects around, which will work against decoupling the app. The
idea is to have the framework manage the DI, so I as the developer don't have to,
achieving a much higher level of decoupling. No singletons in the model, unless you
actually want one.
• Allow for Model's scopes or contexts. The idea that there are Sub-models that can
coexist. (You could call them "scoped singleton's", shared only within a context (scope).
• Allows for easy project growth. As the project grows, it is still easily maintained, and
could be easily re-factored if necessary.
• Easy to learn, quickly to implement.

So we did a little research and came up with the following options:

1. Make our own. Hah hah hah. We are a small team; we can't invest that much time,
especially if there are several great options available.
2. PureMVC. http://puremvc.org/
3. Mate Flex Framework: http://mate.asfusion.com/
4. Swiz Framework: http://swizframework.org/
5. Robotlegs: http://www.robotlegs.org/

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

6. Parsley: http://www.spicefactory.org/parsley/

I'm sure there must be others, but time is limited and I can't devote that much time into looking at
every possible option there is. These are the "better known" pro-MVC Flex frameworks.

Each has their positive side, and depending on your projects you might choose a different
framework for different projects. Unfortunately for us, we can't invest time into getting to know
deeply each one of them.
I did however take time to look at examples and read through the documentation of all of them,
looked at what people like and dislike about each one of them to decide on what to use keeping
in mind the list of what "better" meant for us, considering the projects that we currently have
lined up.

So I'll explain the reasons why we chose to go with Parsley for some of our projects. I really
want to stress that I don't think that any of these frameworks are "wrong", nor "bad". They
implemented similar goals in different ways which have their unique benefits, but we evaluated
their features according to our goals. Your goals will be different, so you should do your own
evaluation.

• PureMVC. The idea is actually good. The goal is to have a framework that works in
multiple environments. So if you code in multiple languages or use multiple platforms, it
sounds good. But to accomplish that, it must make sacrifices and not exploit the Flex's
sdk as it could. The other issue is that it uses a similar singleton approach as Cairngorm
does. So it was out of the contest quickly.
• Mate Flex Framework. A lot of people like Mate, and I understand why. It nearly fills
all of the requirements we were looking for. What I don't like about Mate is its glue
mechanism. Decoupled objects eventually need to be coupled (or glued) together for
your app to work. Mate uses "Map" files that describe how to glue (couple) things
together. Map files are great in the sense that they illustrate the logic of how the app
works. So a developer new to the app, can easily catch on how things are tied together,
something a bit harder in other frameworks. So what's not to like? Well, Map files are
built using MXML, and doing logic in MXML is just weird. I could get used to it, but
what I really don't like is that Map files tie Objects/Models/Commands to properties or
methods, but it does it through string variables. This means that you will not get
compiler errors, and you have to be careful when you re-factor, as to make sure your Map
files also get updated. You have to be even more careful if you use the same property
name in two different components and decide to refactor one of them. Also, I fear that as
the project grows and expands Map files could grow to be a pain to maintain, as they
centralize the coupling of just about everything. I know you can distribute the Map files
into several map files, but I still think it can become a pain. I do like the fact that it
doesn't require custom metatags, and it works well with modules.
• Swiz Framework. Swiz follows a completely different approach on how to wire (glue,
couple) your objects together. Swiz uses and Autowire feature, where objects are glued
"Magically" by themselves. Ok it's not magic, it uses custom metagags, but it doesn't

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

require a Map file. Actually, Parsley and Robot Legs both follow this same basic idea,
where it comes to Dependency Injection. The framework figures out what to inject based
on the properties Class type. You don't have to manually specify it, it just happens at
runtime. You might ask: So what if I have two Models of the same Class type, although
unusual, it's not a problem, it has a simple solution. Actually the way the messaging is
done is similar to Parsley's messaging. So if Swiz and Parsley are so much alike, why
Parsley? Simply put, Parsley has more options. Swiz frameworks messages must be
Flex Events. Parsley's can be Flex Event's but don't have to be. Parsley is more friendly
to Modules, and Parsley's lifecycle is automatically tied to the view lifecycle, which
means that there is even less to worry about. If you wish to control the lifecycle
manually in Parley, you still can. Parsley is simply more mature and more "flexible".
• Robotlegs. Robotlegs is the new kid on the block, and gaining lot's of momentum.
Robotlegs isn't based on Spring like most of the other frameworks. Robotlegs also
provides an implementation of (MVCS, Model View Controller + Service) Robotlegs
does DI in a similar way that Parsley and Swiz do, but messages are handled a bit
different. You use something similar to addEventViewer of Flex, but it's coupled to the
framework and not the specific implementation. It has a similar concept of Context as
Parsley does, but in Robotlegs you must extend a Context class from Robotlegs. Parsley
let's you define the Context as Object in MXML or even in XML and load it at runtime.
Robot Robotlegs includes Mediators, similar to the concept from PureMVC's
mediators. One key aspect of mediators is that they allow you to isolate the view from
the rest of the application. Basically they allow you to have little to no code in the view,
and certainly no logic that ties it to the particular implementation. If that's your goal,
then you can easily to the same with the "Presentation Model (PM)" which Parsley easily
supports. Actually Flex 4 has this concept built in with the new Spark Skins, you can
totally isolate the View from the logic. But in Parsley you can certainly use PMs without
spark skins, or Flex 4. If you really have to have mediators in the PureMVC style, then
you should strongly consider Robotlegs. Which is better? That's a matter of choice, we
have started to use Robotlegs in our latest project for one specific reason: Although
Parsley does allow you to add objects to the context at runtime after the context has been
created, they are treated differently, in Robotlegs, all objects are added to the context
after it's been created, and treated exactly the same, that is a very particular requirement
from us in our latest project. This isn't an issue in the vast majority of projects. In brief,
you can use Robotlegs in a similar fashion as Parsley, or you can follow it's pattern
inspired by pureMVC. The key difference is that in Robot legs you configure and use the
framework through ActionScript, while in Parsley it is done through Metatags, MXML
and/or XML.

In conclusion:
Parsley easily met all our original requirements. It is very flexible, it works in Flex and in
pure AS3 projects (Flex not required, although in it's latest versions it is departing from Flash), it
is simple, it makes sense, it does what you expect it to do, you don't have to extend the
framework, but you can if you want. Parsley is easy and it doesn't require you to write any AS to
tie things together nor to extend any of it's classes. You don't even have to follow an MVC

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

pattern for it to be useful. Actually Parsley is not aimed specifically to implement an MVC
pattern, it just helps you with it, and you can chose any patter that you like.

That doesn't mean it's perfect. Parsley uses custom metatags, which translate to issues with
the compiler. When using RSL's or Modules, you must instruct the compiler to keep the custom
metatags, or it simply won't work, and worse, sometimes it will fail silently. I guess that one
thing that is debatable if it's good or bad is that in Parsley there is more than one way to
accomplish the same thing, it's good because you choose what you like the most, or fits better,
it's bad because it could lead to inconsistency, which could make working as a team a bit more
difficult. Flexibility does have a price, but it's a matter of coordination, and I rather have the
flexibility and use it responsibly than not have it at all.

Well, that's why we chose to use Parsley. I will write a series of articles with examples to help
you get started with Parsley, or just learn about it. It will start with very simple examples, and
move on to more complex scenarios to really show the power behind it.

Quick Dive into Parsley (Parsley's Basic Concepts - Part 2)

This is part of a series of articles that should get you up and started using Spicesfactory's Parsley.
This is part 2. In Part 1, I explained the reasons as to why we chose to use Parsley in our
projects.
In Part 3, we will look at a basic Injection Example.

In this note, I will explain the basic concepts of Parsley, in the next article we will look at a
specific example.

What is Parsley?
Parsley is a framework that helps you write decoupled Flex/Flash/AIR applications written
in ActionScript3. Note that I specifically did not include MVC (Model-View-Controller) in the
description. The reason for excluding MVC in the description is that Parsley is not aimed
towards any specific pattern including MVC. Parsley is a framework that helps you decouple
your application. What this translates to is that your Classes are less tied to a specific
implementation and to each other. This promotes re-usability and it makes it much easier to test
individually. Also it's easier to work in teams, because when a particular person is working in a
Class, he/she should only worry about what that Class is supposed to do, and not about a
particular implementation that might depend on what other are working on. You can more easily
work in parallel when you write decoupled components and Classes.

This is a list of Parsley's main features, extracted directly from Parsley's website:

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

• Flexible IOC Container: Supports configuration with AS3 Metadata, MXML, XML
files, ActionScript
• Dependency Injection: Injection by type or id - for constructors, methods or properties
• Decoupled Bindings: Bindings where source and target are fully decoupled, based on a
publish/subscribe mechanism
• Messaging Framework: Fully decoupled senders and receivers, can serve as a basis for
MVC architectures
• Dynamic View Wiring: Easily wire Flex components to objects declared in the container
• Advanced container features: Asynchronously initializing objects, object lifecycle,
modular configuration contexts
• Integration with Flex Modules: Allows configuration to be loaded and unloaded
alongside Flex Modules
• Localization: Integrates with Flex ResourceManager for Flex Applications, contains its
own Localization Framework for Flash Applications
• Extensibility: Easily create your own configuration tags, a single implementation can be
used as AS3 Metadata, MXML or XML tag

Throughout this series of articles we will see most of these features.

Parsley's Basics
One of the great things about Parsley is that it's not "intrusive". What I mean with not "intrusive"
is that you do not need to extend any of Parsley's classes at all to use Parsley's features. So it is
fairly easy to take components that use Parsley and without having to remove most of the tags,
they will either work with another framework of without a framework at all. Many things are
accomplished in Parsley by using simple Metatags that will be ignored if nothing is there to
interpret them. Of course, you can extend Parsley's Classes if you wish to add more features or
modify features if you like.

Another important aspect is that it doesn't force you into any particular pattern. It is primarily a
decoupling framework. You can follow an MVC pattern, or any other decoupling pattern that
you want. MVC is the buzzword now, but someone will come up with something "better", and if
you are stuck into something specific, well you are... stuck. Parsley is pretty abstract. Some
people don't like this, but I most certainly do. I strongly believe that following patterns is good,
until they start getting in the way of accomplishing your original goal. No pattern is perfect, all
patterns will have their cons, and if their cons really start killing your productivity, it's time to
revise your patterns. Don't just follow them to the book because that's HOW you are supposed to
do it. Patterns should not be unchangeable rules. If your project does not fit well into a specific
pattern, then use a different one or modify it so that it fits well. Just coordinate the changes to
the pattern with the rest of the team.

Some key concepts and how they relate to Parsley:

Managed Objects. Parsley will only manage objects that you specifically instruct it to do so. It

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

will not manage anything without being told to do so. Non-view components (those that are not
added to the stage) are managed by using the ContextBuilder. View component's (those that are
added to the stage through the addChild() method are managed by including the Configure tag.
Parsley manages the complete lifecycle of objects that where added through the ContextBuilder.
Parsley will automatically create new instances as needed and will destroy old instances when
they are not needed. If the class that you want Parsley to manage requires parameters to be sent
to the constructor, Parsley can also do that. Generally speaking, Parsley removes (destroys)
objects when the context that they belong to is destroyed, and the context itself is also destroyed
automatically when the object that created the context is removed (unless it is specifically
instructed not to do so).

Context. If you are coming from Cairngorm 2, there is a reasonable chance that you wished you
had this in Cairngorm. A context in Parsley is somewhat similar to the concept of scope of
class. Objects within the same context can "see" each other, and are available while the context
exists. They can be shared among any other managed object within the same context. Context,
like scopes, can be nested, just like you nest curly brackets { } in AS3 to control scope. The
interesting thing about the way Parsley implement's the context is that the context is
automatically and dynamically wired to the View. In other words, once a component creates a
context, any view child of that container can participate in that same context. This also means
that you can easily have and manage nested contexts, multi-level contexts, or sub-context, or
more private context, however you like to call them.

Dynamic View Wiring. This is a key-point of how Parsley glues objects together. By default,
Parsley's contexts are associated with the view hierarchy. View-children of the component, or
any of its children, can participate in the same context. This is applied to the whole view
hierarchy. The great thing about this is that you don't need to have two hierarchies (one for
Parsley and one for the view), it's all tied to one, the view, which you have to use if you use
Flash/Flex. So things work like you would expect with very little additional configuration, and
it's all part of the same thought process. This also applies to Modules. If a Module is loaded and
added as a view-child, it participates as part of the context its parent belongs to, all done
automatically. The dynamic view wiring model extends through the children of the children of
the children, etc... If you are wondering if you can control the context more manually, the
answer is yes, you can, but you don't have to.

Dependency Injection. Dependency Injection is a concept in which you assign (inject) objects
into other objects. The idea is to keep classes from having to go reach and fetch anything that
they might need, which would tie them to a specific structure or implementation. So rather than
it reaching for its dependencies, you feed the dependencies to it. This is great because the class
can be used for many different things. A simple example is Flex's Lists component. The List
component doesn't go and get its data, you have to assign (inject) its data to it, through its
dataProvider property. This allows the List to be used many times with different data. If this is
great, what is the problem? Well, since you have to feed the data, you need to carry it around in
your views and that ties that view to that data and that implementation. Also, some of your
views may not have a need for specific data yet they will have to carry it around because one of

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

their children might need it. This is one of the reasons why some developers like Global
Variables, they help you avoid having to carry data around, although they are generally speaking
considered a bad idea and bad programming practice. Dependency Injection is not limited to
data, that's just an example. Let's say that rather than carrying data around, you decide to request
the data from a service every time you need it. Well, that does mean you will be making a lot of
(possibly unnecessary) service calls. So you would have to go and setup the service everywhere
you need to. So you decide that you want to setup the service once and use it everywhere, well
then you should inject it into your views so they can use it. Simple, right? Well, so now rather
than hauling your data around, you are doing the same with the Service. Is there a solution
without using Global Variables? YES! Parsley can manage Dependency Injection for you. That
way Parsley carries your objects and injects them where ever you need them. You can easily add
new features. BTW, locally cashing data in the client side is one of the things I really like about
web applications done in Flex/Flash. If you have already fetched some data from some service,
you really should not have to go fetch it again because you are in a different view that uses the
exact same data.

Inversion of Control (IOC): Is a principle that promotes decoupling of an application. It's

called Inversion of control because the flow of control is inverted from traditional procedural
programming. It's commonly associated with the Hollywood (or most auditioning) principle:
"Don't call us, we will call you." In standard procedural programming, you call
methods/functions, and expect an immediate action and response, and then you make your next
call, and expect the same, and so on. Under IOC, that's not the case. You request something to
be done, and when it's done, you will be notified that it's done, you no longer have control of
when exactly things will happen. Flash in itself follows the IOC principle simply because it is
highly event driven; Parsley helps you keep things that way. The main goal derived from IOC is
that you write highly specialized classes that should make little or no assumptions of what other
classes do. This makes it much easier to test and to reuse your classes, also you can swap a Class
and no changes would be required to any other parts of your application. For example, using
IOC you could write an app that writes to a local storage, and when the save is complete it
notifies the user that the save is complete. By using IOC you could simply swap one Class, and
now the application can write to the local storage, contact a remote service, wait for an answer
from the service and when all is done, notify the user that the save was successful after the
service replied. All this and not have to change any other Class, everything continues to work as
it did before. That's because the original implementation using IOC, regardless of the save been
local, the system was still expecting to be notified when the save was complete, and not assumed
it would be taken care of immediately. Essentially, you are using Asynchronous
Communication. It is much easier to extend and add new functionality in the future if you are
using the IOC principle. The drawback to IOC is that creating sequences of tasks is more
involved. The good news is that with Spicelib you also have Tasks Groups that allow you to
create sequences more easily, and still follow IOC principles.

Singletons: Parsley's docs sometimes use the term singleton. Singleton is essentially a single
instance of a class. What Parsley's docs generally refer to as a singleton is a single instance of

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html
by Arturo Alvarado
Parsley

the class within a specific context, and not the common use of singleton that it's a single instance
within the whole application.

Reflection: This term is used often in the docs, and used later in the series, but what does it
mean? Reflection is the capability of a computer program to be able to examine itself and
potentially use that information to change it's behavior at runtime. The keyword is "runtime"
because normally the compiler and linker inspect, and link the code together, but with
Reflection, at runtime you can check what methods exist and call them without them being
explicitly called at compile time. Reflection is a great feature of Flash and ActionScript. In
Parsley terms: Reflection means that Parsley can read and inspect the classes you tell it to, and
call methods, read and assign properties of those classes without that being explicitly coded in
your app. Reflection is what actually allows Parsley to do it's job. Through reflection, Parsley
can know that you want to have a particular instance of some object assigned to a property of
another class and do framework managed dependency injection for example.

Ok, we have gone through some of the basic concepts that are needed to get a good grasp of what
Parsley does and how it works. In the next article we will start with some examples.

http://artinflex.blogspot.com/2010/09/quick-dive-into-
parsley-parsleys-basic.html

http://artinflex.blogspot.com/2010/09/quick-dive-into-parsley-parsleys-basic.html