They are asynchronous but they aren't concurrent. Paul ----- Original Message ----- From: "Jules Suggate" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, December 08, 2008 1:59 PM Subject: Re: [flexcoders] Parsley MVC :: some thoughts
> <boom> head explodes.... heh! > > I have been happily thinking the whole time that events really *are* > asynchronous, but that's obviously not true. Reality check... > > Thanks guys. I think I might have run out of reasons *not* to use Parsley > :) > > On Tue, Dec 9, 2008 at 01:06, Paul Andrews <[EMAIL PROTECTED]> wrote: >> ----- Original Message ----- >> From: "Jules Suggate" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Monday, December 08, 2008 6:49 AM >> Subject: [flexcoders] Parsley MVC :: some thoughts >> >>> Anyone used Parsley MVC? I'm a bit confused by it. >>> >>> There's the standard MVC FrontController class, which exposes a method >>> dispatchEvent() for app-wide notifications. It also has a concept of >>> interceptors which is nice... so far so good. >>> >>> BUT... that dispatchEvent() call executes *synchronously*. Control >>> won't return to your code until *every single listener* to that event >>> finishes executing!! In a single-threaded environment like Flash >>> Player, I would have thought this to be a disastrous design >>> decision... can anyone shed any light on this, as I'm sure there's >>> something I'm missing here! >> >> Why is it disastrous? The flash player is single threaded so it's not >> possible have concurrently running code (something I think that Adobe >> should >> address in the future) so why shouldn't all the waiting listeners be >> called? >> >> It's not possible to resume execution elsewhere while a listener is still >> active because that would require semaphores to handle pseudo concurrency >> and I'm sure that holds true not just for the listeners themselves but >> also >> for the mechanism that calls the waiting listeners. >> >> Paul >> >>> >>> TIA, >>> +J >>> >>> PS another thing I haven't figured out yet is how to inject >>> dependencies into a View component... it seems Parsley can only inject >>> into objects that have been created in the Parsley config file ... and >>> because View components are instantiated by the Flex framework, from >>> what I can tell Parsley has no way to reference them... this has the >>> unpleasant side-effect of requiring all my View code to access the >>> FrontController directly through the FrontController.root static >>> property. >>> >>> In fact, the FrontController class is bugging me -- it is a concrete >>> class with no abstract interface I can code to. It's making me nervous >>> about lock-in to the Parsley framework. >>> >>> Kinda goes against the whole IoC thing, no? >>> >>> PPS And yeah, I will post this to the Parsley forums, but I want the >>> esteemed opinion of those on this list too! >>> >>> ------------------------------------ >>> >>> -- >>> Flexcoders Mailing List >>> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt >>> Alternative FAQ location: >>> >>> https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 >>> Search Archives: >>> http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups >>> Links >>> >>> >>> >> >> > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Alternative FAQ location: > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > >
