Spring ActionScript + Cairngorm Example

[brianmriley]

First, this framework rocks! 3 Thumbs up for porting this over to AS
from the Java world!

I've been working on a pretty large Flex + Java stack with my team for
some time now and I decided to create a tutorial series on it...when I
started I was using SAS 0.7.1 and didn't realize the framework had not
only been adopted by the Spring Community, but was also much farther
along than in it's implementation and had new docs, etc...to that, I
decided to revamp my original Flex + Spring ActionScript ("SAS") +
Cairngorm ("CG") with the new SAS v0.8 and base it on the docs that
explained how to integrate the CG extensions. Here's my current
example with the source exposed -- the accompanying blog post is still
in the works but I wanted to get the SAS Communities take on it --
feel free to rip/slice/dice, whatever, just putting it out there as a
full working example for the community...a starting point if you will.

I provided 2 Login Delegates -- an AS Mock Object Delegate and an XML
Delegate. If you look at the spring-delegates.xml app context file,
you can simply comment/uncomment the desired Delegate Factory and
you're off t the races and running. Now using an AS Mock Obj Del and a
local XML Del doesn't prove much, but if you were to have RemoteObject
Dels in the mix too, then theoretically you could start creating the
app as soon as you perform concrete service identification and
specifications and the Flex dev doesn't have to wait for the server-
side guys to create (even mocked up) RO services.

Also, one of the guys on my team asked why I bother injecting the
Model Locator ("ML") since there's only one in the app...well, in an
effort to further decouple the app, if you were to create say another
hardcoded, AS Mock Object ML then you can start developing the views
as soon as your client-side domain model has been established...and
even better than that is that you can now test each layer of your
application completely independent of whether or not others work or
are ready for primetime -- would be really nice to test a view's data
bindings to the ML without having to recompile the app with one
hardcoded ML and one real ML that has to ge data from the Commands.
Beautiful.

Here's a couple things that I noticed while building the app that
didn't quite add up:

1) AutoWiring MXML view components didn't seem to work for me unless I
added the components to the stage after (and only after) all the app
context files had been loaded (parsed, objects instantiated and
cached, etc). You'll notice in my main, Application class that I have
my MainView in MXML commented out and that I'm adding it to the stage
after the app context files load. Maybe I missed something to make
this work correctly -- download the app and give it a look.

2) The Service Locator ("SL") seems superfluous, as the delegates are
injecting the serfvices based on the references for the actual service
object definitions. If you think about it, with SAS, a spring-
services.xml application context file "is" the SL. Thoughts?

3) When I first created the example, I made it a combined Flex + Java
project in WTP, so naturally my Flex app ran on a web server...uh oh,
now my XML app context files get cached...I saw that you guys removed
the lined to kill caching with the random number b/c this didn't seem
to work for Flex project's not running on a web server -- that might
be IE only to be honest. Firefox works fine with this. Anyways, I
added that line back in when laoding the XML files to fix the problem:

var killCaching:String = "";
killCaching += ("?" + Math.round(Math.random() * 1000000));

and then appended that to the end of each app context file URL.

Perhaps you can just put in an additional param in the constructor for
the AppContextLoader that allows devs to say yes, add kill cache or
not? You can also do some tricks to determine if the app is running on
a web server or not inside the class so it's not up to the dev.

4) I believe many have already commented on this, but there seems to
be number of stack traces when the app context is first firing up,
although they're not real errs and don't cause the app to bomb -- most
of them take this form:

Fri Jun 26 16:21:13 GMT-0400 2009 [DEBUG] org.as3commons.reflect.Type
- Error while instantiating class [class Event] with null arguments in
order to retrieve constructor argument types: TypeError, 2007
Message: Error #2007: Parameter type must be non-null.
Stack trace: TypeError: Error #2007: Parameter type must be non-null.
at flash.events::Event()
at org.as3commons.lang::ClassUtils$/newInstance()[C:\workspace
\as3commons\as3-commons-lang\src\main\actionscript\org\as3commons\lang
\ClassUtils.as:316]
at org.as3commons.reflect::Type$/_getTypeDescription()[C:\workspace
\as3commons\as3-commons-reflect\src\main\actionscript\org\as3commons
\reflect\Type.as:362]
at org.as3commons.reflect::Type$/forClass()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:172]
at org.as3commons.reflect::Type$/forName()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:143]
at TypeXmlParser$/parseParameters()[C:\workspace\as3commons\as3-
commons-reflect\src\main\actionscript\org\as3commons\reflect\Type.as:
442]
at TypeXmlParser$/parseMethodsByModifier()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:430]
at TypeXmlParser$/parseMethods()[C:\workspace\as3commons\as3-commons-
reflect\src\main\actionscript\org\as3commons\reflect\Type.as:405]
at org.as3commons.reflect::Type$/forClass()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:181]
at org.as3commons.reflect::Type$/forName()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:143]
at TypeXmlParser$/parseParameters()[C:\workspace\as3commons\as3-
commons-reflect\src\main\actionscript\org\as3commons\reflect\Type.as:
442]
at TypeXmlParser$/parseConstructor()[C:\workspace\as3commons\as3-
commons-reflect\src\main\actionscript\org\as3commons\reflect\Type.as:
396]
at org.as3commons.reflect::Type$/forClass()[C:\workspace\as3commons
\as3-commons-reflect\src\main\actionscript\org\as3commons\reflect
\Type.as:179]
at
org.springextensions.actionscript.ioc.factory.support::AbstractObjectFactory/
getObject()[/Users/brianmriley/projects/spring-hibernate/workspaces/
emp-mgmt-console/SpringActionScript/trunk/core/src/main/actionscript/
org/springextensions/actionscript/ioc/factory/support/
AbstractObjectFactory.as:193]
at
org.springextensions.actionscript.ioc.factory.support::DefaultListableObjectFactory/
preInstantiateSingletons()[/Users/brianmriley/projects/spring-
hibernate/workspaces/emp-mgmt-console/SpringActionScript/trunk/core/
src/main/actionscript/org/springextensions/actionscript/ioc/factory/
support/DefaultListableObjectFactory.as:144]
at
org.springextensions.actionscript.context.support::XMLApplicationContext/
afterParse()[/Users/brianmriley/projects/spring-hibernate/workspaces/
emp-mgmt-console/SpringActionScript/trunk/core/src/main/actionscript/
org/springextensions/actionscript/context/support/
XMLApplicationContext.as:171]
at
org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/
_doParse()[/Users/brianmriley/projects/spring-hibernate/workspaces/emp-
mgmt-console/SpringActionScript/trunk/core/src/main/actionscript/org/
springextensions/actionscript/ioc/factory/xml/XMLObjectFactory.as:346]
at
org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/
_loadNextProperties()[/Users/brianmriley/projects/spring-hibernate/
workspaces/emp-mgmt-console/SpringActionScript/trunk/core/src/main/
actionscript/org/springextensions/actionscript/ioc/factory/xml/
XMLObjectFactory.as:317]
at
org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/
_loadNextConfigLocation()[/Users/brianmriley/projects/spring-hibernate/
workspaces/emp-mgmt-console/SpringActionScript/trunk/core/src/main/
actionscript/org/springextensions/actionscript/ioc/factory/xml/
XMLObjectFactory.as:294]
at
org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/
_onLoaderComplete()[/Users/brianmriley/projects/spring-hibernate/
workspaces/emp-mgmt-console/SpringActionScript/trunk/core/src/main/
actionscript/org/springextensions/actionscript/ioc/factory/xml/
XMLObjectFactory.as:246]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()

You can view the completed application here with view source enabled:

http://www.webappsolution.com/flex/blog/examples/emp-mgmt-console-5/EmployeeManagementConsole5.html
http://www.webappsolution.com/flex/blog/examples/emp-mgmt-console-5/srcview/index.html

The frameworks rocks and I'm a huge fan for many reasons! Keep it up
and I'll do my best to keep digging into the new versions and helping
out where possible.

You guys rock!
-riley
http://www.webappsolution.com/
http://www.webappsolution.com/wordpress/

[Christophe Herreman]

Hi Brian,

here's some feedback.

On Jun 26, 11:06 pm, brianmriley <brian.matthew.ri...@gmail.com>
wrote:

> First, this framework rocks! 3 Thumbs up for porting this over to AS
> from the Java world!

Thanks!

>
> I've been working on a pretty large Flex + Java stack with my team for
> some time now and I decided to create a tutorial series on it...when I
> started I was using SAS 0.7.1 and didn't realize the framework had not
> only been adopted by the Spring Community, but was also much farther
> along than in it's implementation and had new docs, etc...to that, I
> decided to revamp my original Flex + Spring ActionScript ("SAS") +
> Cairngorm ("CG") with the new SAS v0.8 and base it on the docs that
> explained how to integrate the CG extensions. Here's my current
> example with the source exposed -- the accompanying blog post is still
> in the works but I wanted to get the SAS Communities take on it --
> feel free to rip/slice/dice, whatever, just putting it out there as a
> full working example for the community...a starting point if you will.

We'll try to release 0.8 asap. It's in a bit of a delay with the
changes we did towards the AS3Commons project.

>
> I provided 2 Login Delegates -- an AS Mock Object Delegate and an XML
> Delegate. If you look at the spring-delegates.xml app context file,
> you can simply comment/uncomment the desired Delegate Factory and
> you're off t the races and running. Now using an AS Mock Obj Del and a
> local XML Del doesn't prove much, but if you were to have RemoteObject
> Dels in the mix too, then theoretically you could start creating the
> app as soon as you perform concrete service identification and
> specifications and the Flex dev doesn't have to wait for the server-
> side guys to create (even mocked up) RO services.

Seems like the way to go. I also implemented this in the modified
Cairngorm example store.

>
> Also, one of the guys on my team asked why I bother injecting the
> Model Locator ("ML") since there's only one in the app...well, in an
> effort to further decouple the app, if you were to create say another
> hardcoded, AS Mock Object ML then you can start developing the views
> as soon as your client-side domain model has been established...and
> even better than that is that you can now test each layer of your
> application completely independent of whether or not others work or
> are ready for primetime -- would be really nice to test a view's data
> bindings to the ML without having to recompile the app with one
> hardcoded ML and one real ML that has to ge data from the Commands.
> Beautiful.

Injecting is without any doubt more flexible than having the ML
referenced directly in your code. It's up to you to decide where it is
appropriate, but as you say, mocking can be quite handy and powerful.

>
> Here's a couple things that I noticed while building the app that
> didn't quite add up:
>
> 1) AutoWiring MXML view components didn't seem to work for me unless I
> added the components to the stage after (and only after) all the app
> context files had been loaded (parsed, objects instantiated and
> cached, etc). You'll notice in my main, Application class that I have
> my MainView in MXML commented out and that I'm adding it to the stage
> after the app context files load. Maybe I missed something to make
> this work correctly -- download the app and give it a look.

I thought we fixed that already. The problem is/was that the ADDED
events on the systemmanager were fired before the context was loaded,
so we could not intercept the UI component and autowire them. Is it
possible to test this again?

>
> 2) The Service Locator ("SL") seems superfluous, as the delegates are
> injecting the serfvices based on the references for the actual service
> object definitions. If you think about it, with SAS, a spring-
> services.xml application context file "is" the SL. Thoughts?

My thoughts exactly. There is no need for service lookup if you use
DI.

>
> 3) When I first created the example, I made it a combined Flex + Java
> project in WTP, so naturally my Flex app ran on a web server...uh oh,
> now my XML app context files get cached...I saw that you guys removed
> the lined to kill caching with the random number b/c this didn't seem
> to work for Flex project's not running on a web server -- that might
> be IE only to be honest. Firefox works fine with this. Anyways, I
> added that line back in when laoding the XML files to fix the problem:
>
> var killCaching:String = "";
> killCaching += ("?" + Math.round(Math.random() * 1000000));
>
> and then appended that to the end of each app context file URL.
>
> Perhaps you can just put in an additional param in the constructor for
> the AppContextLoader that allows devs to say yes, add kill cache or
> not? You can also do some tricks to determine if the app is running on
> a web server or not inside the class so it's not up to the dev.

We should indeed make this more enhanced. I would vote for an
automated approach (autodetect environment etc). This should probably
be something to work on for the 0.9 release.

We need to do a little hack in as3commons-reflect to work around a
flash player bug in order to retrieve correct constructor argument
information. We also put in the debug logs to inform devs about it.
You can easily filter these out by configuring the FlexLoggerFactory
and adding filters on the mx Log class.

Here's how logging is currently configured in an app we are working
on:

private static var loggerSetup:* = setupLogging();
private static var logger:ILogger = LoggerFactory.getLogger
("TMSNG.Main");

private static function setupLogging():void {
LoggerFactory.loggerFactory = new FlexLoggerFactory();

var traceTarget:TraceTarget = new TraceTarget();
traceTarget.includeCategory = true;
traceTarget.includeDate = true;
traceTarget.includeLevel = true;
traceTarget.includeTime = true;
traceTarget.filters = ["TMSNG.*"];
Log.addTarget(traceTarget);

var traceTargetSpring:TraceTarget = new TraceTarget();
traceTargetSpring.includeCategory = true;
traceTargetSpring.includeDate = true;
traceTargetSpring.includeLevel = true;
traceTargetSpring.includeTime = true;
traceTargetSpring.level = LogEventLevel.INFO;
traceTargetSpring.filters = ["org.springextensions.*"];
Log.addTarget(traceTargetSpring);

var traceTargetReflect:TraceTarget = new TraceTarget();
traceTargetReflect.includeCategory = true;
traceTargetReflect.includeDate = true;
traceTargetReflect.includeLevel = true;
traceTargetReflect.includeTime = true;
traceTargetReflect.level = LogEventLevel.WARN;
traceTargetReflect.filters = ["org.as3commons.reflect.*"];
Log.addTarget(traceTargetReflect);

}

> You can view the completed application here with view source enabled:
>

> http://www.webappsolution.com/flex/blog/examples/emp-mgmt-console-5/E...http://www.webappsolution.com/flex/blog/examples/emp-mgmt-console-5/s...
>

I'll tweet this when it is publised. Good stuff!

> The frameworks rocks and I'm a huge fan for many reasons! Keep it up
> and I'll do my best to keep digging into the new versions and helping
> out where possible.

Thanks again for the support. We appreciate it.

>
> You guys rock!
> -rileyhttp://www.webappsolution.com/http://www.webappsolution.com/wordpress/

[Roland Zwaga]

Hey there,

can I chime in on a few subjects too? :)

> > 1) AutoWiring MXML view components didn't seem to work for me unless I
> > added the components to the stage after (and only after) all the app
> > context files had been loaded (parsed, objects instantiated and
> > cached, etc). You'll notice in my main, Application class that I have
> > my MainView in MXML commented out and that I'm adding it to the stage
> > after the app context files load. Maybe I missed something to make
> > this work correctly -- download the app and give it a look.
>
> I thought we fixed that already. The problem is/was that the ADDED
> events on the systemmanager were fired before the context was loaded,
> so we could not intercept the UI component and autowire them. Is it
> possible to test this again?

I'm very interested in this as well, I received a similar complaint on
the forums and
when I suggested they use the latest source from SVN it was claimed
that the
problem had disappeared. Did you develop with the latest trunk as
well?

> > 2) The Service Locator ("SL") seems superfluous, as the delegates are
> > injecting the serfvices based on the references for the actual service
> > object definitions. If you think about it, with SAS, a spring-
> > services.xml application context file "is" the SL. Thoughts?
>
> My thoughts exactly. There is no need for service lookup if you use
> DI.

I don't completely agree with you guys here, in *most* cases its true,
but in an online/offline
situation (like in a lot of AIR applications) I think the
servicelocator could be an ideal
candidate to perform an online/offline check and return a different
delegate respectively.
So one that that'll save locally and one that'll save remotely.

> > var killCaching:String = "";
> > killCaching += ("?" + Math.round(Math.random() * 1000000));
>
> > and then appended that to the end of each app context file URL.
>
> > Perhaps you can just put in an additional param in the constructor for
> > the AppContextLoader that allows devs to say yes, add kill cache or
> > not? You can also do some tricks to determine if the app is running on
> > a web server or not inside the class so it's not up to the dev.
>
> We should indeed make this more enhanced. I would vote for an
> automated approach (autodetect environment etc). This should probably
> be something to work on for the 0.9 release.

I'd also like to investigate whether its possible to circumvent
caching by adding
certain http header to the remoteobject call, if that would work it
just feels less 'hacky' :)
But I agree with Christophe, that's a v0.9 issue :)

cheers!

Roland

[brianmriley]

Roland:

You can absolutely chime in -- I pushed this example to the group to
facilitate a discussion and get feedback whether or god or bad. ;-)

So thanks for your thoughts!

CH, thanks for your info on the logger and setting it up to remove the
debug stmts spit out by the Reflect project -- I should've thought
about filtering them ;-) but I like that we're aware of them as well.

I'll add that into the example as well with a thick comment explaining
it per your reply.

>>>Hey there,

>>>can I chime in on a few subjects too? :)

>1) AutoWiring MXML view components didn't seem to work for me unless I
>added the components to the stage after (and only after) all the app
>context files had been loaded (parsed, objects instantiated and
>cached, etc). You'll notice in my main, Application class that I have
>my MainView in MXML commented out and that I'm adding it to the stage
>after the app context files load. Maybe I missed something to make
>this work correctly -- download the app and give it a look.

>>I thought we fixed that already. The problem is/was that the ADDED
>>events on the systemmanager were fired before the context was loaded,
>>so we could not intercept the UI component and autowire them. Is it
>>possible to test this again?

>>>I'm very interested in this as well, I received a similar complaint on
>>>the forums and
>>>when I suggested they use the latest source from SVN it was claimed
>>>that the
>>>problem had disappeared. Did you develop with the latest trunk as
>>>well?

I pulled the latest SVN trunk as June 25 last wk and ran the maven
build to produce the spring-actionscript-0.8-SNAPSHOT.swc. If someone
has a v.8 SWC lying around, pull my project source and switch out my
SWC with yours just to make sure; then take a look at
EmployeeManagementConsole5.mxml and comment out the AS code block in
the app context load handler that adds the MainView to the stage and
uncomment the MXML that adds it to the stage.

>2) The Service Locator ("SL") seems superfluous, as the delegates are
>injecting the serfvices based on the references for the actual service
>object definitions. If you think about it, with SAS, a spring-
>services.xml application context file "is" the SL. Thoughts?

>>My thoughts exactly. There is no need for service lookup if you use
>>DI.

>>>I don't completely agree with you guys here, in *most* cases its true,
>>>but in an online/offline
>>>situation (like in a lot of AIR applications) I think the
>>>servicelocator could be an ideal
>>>candidate to perform an online/offline check and return a different
>>>delegate respectively.
>>>So one that that'll save locally and one that'll save remotely.

That's a good point and I can absolutely see where this would be
appropriate. And after giving it some more thought, I have another
reason I think it could be useful -- right now, in order to change my
services, I have to modify them in my spring-delegates.xml app context
file:

<object id="employeeListDelegateFactory"
class="org.springextensions.actionscript.cairngorm.business.BusinessDelegateFactory">
<property name="service" ref="employeeListXMLService"/>
<property name="delegateClass" type="Class"
value="com.wasi.employeeconsole.business.delegates.employee.EmployeeListXMLDelegate" /
>
</object>

and I'd rather just modify them in the SL...in order to create
separate service types (AS, XML, RO), I need to define each of these
and then inject the desired one in my delegate....I'd rather just have
a generic ref in my Delegate like "employeeListService" and then chg
my SL in my spring-services.xml to point to the desired service...not
really that big of a chg at the end of the day, but it does make more
sense from a patterns perspective.

In order to do this, I'll have to chg the current impl in my PoC to
grab the services from the SL as opposed to injecting them directly in
to the Delegates; I'll need to modify
my org.springextensions.actionscript.cairngorm.business.BusinessDelegateFactory
(which creates each Delegate and injects the service listed in my
spring-delegates.xml app context file) by making it grab the services
from the SL instead of a direct DI there.

>var killCaching:String = "";
>killCaching += ("?" + Math.round(Math.random() * 1000000));

>and then appended that to the end of each app context file URL.

>Perhaps you can just put in an additional param in the constructor for
>the AppContextLoader that allows devs to say yes, add kill cache or
>not? You can also do some tricks to determine if the app is running on
>a web server or not inside the class so it's not up to the dev.

>>We should indeed make this more enhanced. I would vote for an
>>automated approach (autodetect environment etc). This should probably
>>be something to work on for the 0.9 release.

>>>I'd also like to investigate whether its possible to circumvent
>>>caching by adding
>>>certain http header to the remoteobject call, if that would work it
>>>just feels less 'hacky' :)
>>>But I agree with Christophe, that's a v0.9 issue :)

I'll try and dig up some old code I used for Flash apps back in the
day that determined what environment it was running from and see if I
can reuse it for this...


>>>cheers!

>>>Roland

Thanks,
-riley

[Roland Zwaga]

> I pulled the latest SVN trunk as June 25 last wk and ran the maven
> build to produce the spring-actionscript-0.8-SNAPSHOT.swc. If someone
> has a v.8 SWC lying around, pull my project source and switch out my
> SWC with yours just to make sure; then take a look at
> EmployeeManagementConsole5.mxml and comment out the AS code block in
> the app context load handler that adds the MainView to the stage and
> uncomment the MXML that adds it to the stage.

Hey Riley,

I downloaded your project and have been investigating a little, it
*seems* to me
like the Event.ADDED doesn't get fired for all components, apparently.
I added a bunch of traces in the FlexXMLApplicationContext and lo and
behold,
I see traces for the components *inside* your mainView component, but
NOT
for the mainView component itself... I've been using this technique in
several projects
and this is the first time I encounter something like this, weird...
I'm quite baffled to be honest, I'm going to spend some time on this
this evening to
see if I can find out more about this.
I'll report back with my findings.

cheers,

Roland

[Roland Zwaga]

Hey guys,

I've been screwing around with the Event.ADDED for a bit and have come
to the conclusion that it fires unreliably
in the FlexXMLApplicationContext caching code. I have a suspicion that
it has something to do with the fact that the event
handler was a static function, for which I had no choice because I had
to cache components *before* any FlexXMLApplicationContext
was even instantiated. I'm not sure if we're dealing with a player bug
here or something else than I'm missing alltogether.

Bottom line is that I simply removed the entire caching scheme and
chose to go for the brute-force way. From now on the
FlexXMLApplicationContext waits until it has loaded and parsed its
configuration, right after that it loops through the entire
displaylist
of the stage and tries to wire each and every component enountered.
This sounds like a heavy piece of work, but I'm convinced that it's
more than fast enough. Plus, if you have 50 components on your
stage that are dependent on the application context to be ready, its
not even a good idea to have them on the stage beforehand in the first
place.

IMHO of course!

Anyways, I have changed and committed the FlexXMLApplicationContext, I
used Riley's test app to verify its functionality but it wouldn't hurt
at all
if some other people gave this a little spin as well. :)

I say cheers, as per usual :)

Roland

[brianmriley]

Thanks for digging into this...I'll dig around a bit as well.

[Christophe Herreman]

FYI: I just did an SVN update, compiled our project at work and all seems fine.

2009/6/30 brianmriley <brian.mat...@gmail.com>

--
Christophe Herreman
http://www.herrodius.com
http://www.pranaframework.org

[Roland Zwaga]

Cool, thanks you both, I'll consider the issue 'fixed' for now then

On Jun 30, 9:11 pm, Christophe Herreman

<christophe.herre...@gmail.com> wrote:
> FYI: I just did an SVN update, compiled our project at work and all seems
> fine.
>

> 2009/6/30 brianmriley <brian.matthew.ri...@gmail.com>

[brianmriley]

At first I thought this wasn't fixed entirely, but then I did some
digging and put in a fix in my app...

so I pulled a new vr of SAS from SVN and ran a "mvn clean install" and
replaced my old spring-actionscript-0.8-SNAPSHOT.swc with the newly
created one...then I commented out the AS addChil(mainView) block:

// var mainView:MainView = new MainView();
// this.addChild(mainView);

and uncommented my MXML MainView:

<main:MainView id="mainView" />

and I can see in the logs that the MainView does have it's
applicationModel Autowired as expected -- here's the logs:

[SWF] Users:brianmriley:projects:spring-hibernate:workspaces:emp-mgmt-
console:EmployeeManagementConsole5:bin-
debug:EmployeeManagementConsole5.swf - 1,747,359 bytes after
decompression
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
com.wasi.employeeconsole.view.login.LoginView - init
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
com.wasi.employeeconsole.view.main.MainView - init
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
com.wasi.employeeconsole.view.main.MainView -
isUserAuthenticatedChgHandler = false
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
init
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
loadSpringAppContext
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading object definitions
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading XML object definitions from [assets/spring-actionscript/
application-context/spring-services.xml?610368]
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
mainViewAddedHandler addedToStage
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
mainViewAddedHandler added
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading XML object definitions from [assets/spring-actionscript/
application-context/spring-delegates.xml?610368]
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading XML object definitions from [assets/spring-actionscript/
application-context/spring-commands.xml?610368]
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading XML object definitions from [assets/spring-actionscript/
application-context/spring-models.xml?610368]
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.xml.XMLObjectFactory -
Loading XML object definitions from [assets/spring-actionscript/
application-context/spring-front-controller.xml?610368]
Wed Jul 1 15:48:46 GMT-0400 2009 [INFO]
org.springextensions.actionscript.ioc.factory.support.DefaultListableObjectFactory
- Pre-instantiating singletons in [object FlexXMLApplicationContext]
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Can't find a prototype scoped IObjectDefinition whose type match the
object type for EmployeeManagementConsole5_0.mainView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Using default IObjectDefinition for
EmployeeManagementConsole5_0.mainView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.factory.support.AbstractObjectFactory
- Autowiring by type
'com.wasi.employeeconsole.view.main::MainView.applicationModel' with
'applicationModel'
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
com.wasi.employeeconsole.view.main.MainView - set applicationModel
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Can't find a prototype scoped IObjectDefinition whose type match the
object type for
EmployeeManagementConsole5_0.mainView.mainContainer.loginView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Using default IObjectDefinition for
EmployeeManagementConsole5_0.mainView.mainContainer.loginView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Can't find a prototype scoped IObjectDefinition whose type match the
object type for
EmployeeManagementConsole5_0.mainView.mainContainer.consoleView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG]
org.springextensions.actionscript.ioc.wire.DefaultObjectDefinitionResolver
- Using default IObjectDefinition for
EmployeeManagementConsole5_0.mainView.mainContainer.consoleView
Wed Jul 1 15:48:46 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
Application applicationContextLoadResult
--------------------------------------------
Spring ActionScript Context Filed Loaded
--------------------------------------------
Wed Jul 1 15:49:38 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
mainViewAddedHandler added
Wed Jul 1 15:49:39 GMT-0400 2009 [DEBUG] EmployeeManagementConsole5 -
mainViewAddedHandler added

so far, so good, as you can see that the autowiring does take
place...however, if you were to try logging in you'd see that the
screen doesn't chg...this is b/c I set all my data bindings in the
view to the model in the completeCreate event, and at this point the
model hasn't been injected yet...I put in a couple checks to fix this
and it works accordingly. The same would happen if I wasn't using DB
and listening for events from the model...

Here's the take away: if you're setting up event listening or data
binding, make sure the object you're "listening" to has actually been
injected before you try setting up the listeners...you could of course
abstract this code into a base view so you don't have to do this every
time. I'll push the new example up shortly.

[brianmriley]

Or just add the view to the stage via AS like I originally did and you
don't have to worry about this...