Using Event.ADDED means complex objects can't be autowired

5 views
Skip to first unread message

Richard Lord

unread,
Jun 5, 2010, 1:42:11 PM6/5/10
to springactionscript-dev
Hi all

Sorry to crash in here. I've been looking at Spring Actionscript in
the context of my comparison of frameworks (http://www.richardlord.net/
presentations/application-frameworks-the-good-the-bad-and-the-ugly)
and I notice an issue (and a solution - which is why I'm telling you
here rather than the user forum).

My natural tendency is to create my context as early as possible, so
in one test I'm creating the context on the preinitialize event of my
Application (with embedded xml so it's immediate). I'm also autowiring
my view components using metadata annotations.

Unfortunately, Flex creates all the children of the Application object
and adds them to that object before adding the Application object to
the SystemManager. As a result, each components Event.ADDED bubbles as
far as the Application object and then stops, failing to reach the
SystemManager and so not being autowired.

Now, one solution is to wait for the applicationComplete event before
creating the context, by which time all the components are on the
stage and so the context will autowire them. But that only delays the
issue until some other component is added to the stage after its
children are created.

If you use the Event.ADDED_TO_STAGE event, with capture set to true
(the ADDED_TO_STAGE event doesn't bubble, but it does have a full
capture phase) then all children of a component will be autowired when
their parent is added to the stage. I tried this, changing line 228 of
FlexStageProcessorRegistry to
_systemManager.addEventListener(Event.ADDED_TO_STAGE, added_handler,
true);
and it works - I can now create the context on the preinitialize
event. I don't know if there are any negative ramifications to this,
but it seems like a good idea to me.

If you choose not to implement this change, I'd suggest adding details
to the docs to explain that autowiring of view components only works
if the context is created after the applicationComplete event.

Good luck getting to the 1.0 release.

Richard

Roland

unread,
Jun 7, 2010, 3:27:54 AM6/7/10
to springactionscript-dev
Hi Richard,

thanks a lot for that nugget! I had played around with the
added_to_stage event already because
I thought it'd be a better candidate than event.added, but somehow in
my tests the event didn't
seem to fire reliably. It never occured to me to use the capture
phase. I made the change and all
unit tests run fine, so I've committed the change.
Thanks a lot for the tip, this will make the whole stage wiring a lot
more robust.
I'm excited to hear you're including Spring Actionscript in your
framework comparison presentation as well
and am very interested in how it'll weigh up against the other
frameworks in your opinion. If you'd like us
to take a look at the Spring AS specific code you're creating for it,
don't hesitate to drop us a line.

cheers,

Roland

Richard Lord

unread,
Jun 9, 2010, 10:29:56 AM6/9/10
to springactionscript-dev
Hi Roland

Glad to help.

I just posted an example built with Spring Actionscript on my website
and would love feedback - http://www.richardlord.net/blog/flexcaster-spring

I'm including Spring Actionscript in my session at <a href="http://
www.gotoandski.com/">GotoAndSki</a> this Saturday. Still weighing up
my opinion, and as usual with my framework sessions I'll try to
present the facts and let others choose.

But, having worked with SpringAS, here's a few thoughts...

1. The documentation is very comprehensive but also rather heavy for
beginners (this is a feature of the Spring Java documentation too).
It's great to have all this information, but a simpler document
showing just what a beginner needs to know to create a simple app
using one recommended architecture would, I suspect, help with the
uptake from less experienced developers. I should add, however, that
given my knowledge of both Spring Java and Flex I found Spring
Actionscript very easy to understand.

2. The need to include the autowiringStageProcessor and
eventhandlerProcessor in the config makes a lot of sense but I suspect
will appear like config for the sake of it to most flash/flex
developers. Adding a config option to "use the defaults" (something
like Spring Java's <mvc:annotation-driven/>) would help here. When I
had the problem mentioned above, I spent some time suspecting I'd
failed to include another config setting and searching in the docs and
example projects for it before discovering the real cause of the
issue.

3. I chose to embed the xml file because I don't see much value in
loading an xml config at runtime. Without a decent class-loader to
dynamically load classes I think dynamic runtime configuration has
little to offer me, and the majority of flex developers. I may well be
wrong here so go with your conviction, but if you haven't considered
it then maybe embedding the xml file should be your default
recommendation.

That's all. I like Spring Actionscript a lot, and having recently done
a lot of work with Spring Java it slotted straight in with what I
already know. This is likely its greatest strength - Java developers
will understand it immediately.

Cheers
Richard.

Christophe Herreman

unread,
Jun 9, 2010, 10:49:55 AM6/9/10
to springactionscript-dev
Hi Richard,

also thanks from my part for your input on the project.

Here's some feedback on your thoughts:

1. Agreed. The documentation is comprehensive which might give the
impression of a steep learning curve and I have received similar
feedback from others as well. I think a quickstart guide might be a
good idea. On the other hand, as you mentioned, for people familiar
with Java Spring the documentation is more of a quick and extended
reference as they already know most of the concepts of the framework.
We should definitely make efforts to achieve an easier entry into the
framework.

2. I'm actually in the process of adding a "context" namespace to the
XML config that provides a shortcut to include the most common post
processors. This will be included in the final 1.0 release.

3. It's hard to draw a straight line into this. I agree that for many
projects external configuration might not be needed. In that case you
can either use MXML configuration or embed the XML as you did. On the
other hand, besides not having a class loader, external XML config
does have benefits. I'm thinking:
- swapping service endpoints between test and deployment servers
(although you could also load external properties into MXML config for
instance)
- editing certain settings that are specific to the deployment
- generating a dynamic XML config through some middleware (this is
extremely powerful in fact as you don't need a custom XML dialect and
parsers)

I guess the last point depends a lot on what type of projects you are
creating. For the most of us Spring AS developers, we are working on
software that is deployed in several locations that all require there
specific configurations. It would be unwise I think to make a new
build for every installation we have as this would not be maintainable
and time consuming.

Again, thanks for your feedback.

best regards,
Christophe

On Jun 9, 4:29 pm, Richard Lord <rich...@bigroom.co.uk> wrote:
> Hi Roland
>
> Glad to help.
>
> I just posted an example built with Spring Actionscript on my website
> and would love feedback -http://www.richardlord.net/blog/flexcaster-spring
>
> I'm including Spring Actionscript in my session at <a href="http://www.gotoandski.com/">GotoAndSki</a> this Saturday. Still weighing up
Reply all
Reply to author
Forward
0 new messages