Re: [flexcoders] Parsley MVC :: some thoughts
How can something be asynchronous but not concurrent? Asynchronous means that control returns from the function call immediately although the transaction triggered by the call may still be ongoing. To me, that absolutely *requires* concurrency, even if it's simulated through a timeslicing scheduler or some such. I'm pretty sure for something to be asynchronous there has to be some sort of interleaving. That's the whole point of what I just realised: there is no such interleaving within the Flex framework. Event dispatch in Flex/Flash is a *blocking* operation. There's no scheduler or anything within the event bus. Maybe your handlers will make calls to a truly asynchronous API like network calls or something, but until they make that call and return control to the code that dispatched the event, the next line of code in your event producer object will *not* execute. I'm just freaked out that I never realised this. How have my applications even been *usable* until now?!?!? Pure luck and good API design from Adobe/Macromedia. Cheers to the Player team! On Tue, Dec 9, 2008 at 03:02, Paul Andrews [EMAIL PROTECTED] wrote: They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
Not exactly, asynchronous simply means your event handler will fire some time in the future, rather than when you call addEventListener(). Not everything is a blocking dispatch, either IIRC. Concurrent means there's multiple things going on at the same time. Most of the time there's *nothing* going on, really :) On Tue, Dec 9, 2008 at 6:55 PM, Jules Suggate [EMAIL PROTECTED]wrote: How can something be asynchronous but not concurrent? Asynchronous means that control returns from the function call immediately although the transaction triggered by the call may still be ongoing. To me, that absolutely *requires* concurrency, even if it's simulated through a timeslicing scheduler or some such. I'm pretty sure for something to be asynchronous there has to be some sort of interleaving. That's the whole point of what I just realised: there is no such interleaving within the Flex framework. Event dispatch in Flex/Flash is a *blocking* operation. There's no scheduler or anything within the event bus. Maybe your handlers will make calls to a truly asynchronous API like network calls or something, but until they make that call and return control to the code that dispatched the event, the next line of code in your event producer object will *not* execute. I'm just freaked out that I never realised this. How have my applications even been *usable* until now?!?!? Pure luck and good API design from Adobe/Macromedia. Cheers to the Player team! On Tue, Dec 9, 2008 at 03:02, Paul Andrews [EMAIL PROTECTED] wrote: They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
Jules, I confess I actually misread your original post - I had anticipated that when an event is despatch it wouldn't be actioned until the current code section had been completed then the player would act upon events awaiting despatch. On the face of it, if events are despatched and all handlers invoked synchronously before the next statement runs then there's an opportunity for an unexpected race condition if handlers are updating the same data structures as the code that despatched the event. Like you I would be surprised at this behaviour and I might try and check that out for myself later today. So you are right my comments don't match your findings. I don't have a problem with the event despatcher invoking all handlers for an event in sequence - event handling has a predefined order through the display list, but there's no guarantee that multiple handlers at the same place in the hierarchy will be invoked in a set sequence. I'm somewhat surprised at your assertion that despatching an event will invoke handlers for that event synchronously - it would be interesting to get a better handle on this from someone who knows thelow-level mechanism more intimately than I do. My event handling code doesn't anticipate that despatched events are handled syncronously and as i've already said, there's always a danger of an unexpected race condition if that were true. In my previous life writing a lot of code running on multiprocessor systems we took great care to control asynchronous behaviour and to protect data structures from multiple updates using semaphores. In a faux system like the flash player, there isn't true concurrency, but if what you say is true there would be a real potential of getting an unwanted side-effect since effectively shared data structures would be open to being updated unexpectedly whenever an event is despatched. So, I'm kinda with you. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Tuesday, December 09, 2008 8:55 AM Subject: Re: [flexcoders] Parsley MVC :: some thoughts How can something be asynchronous but not concurrent? Asynchronous means that control returns from the function call immediately although the transaction triggered by the call may still be ongoing. To me, that absolutely *requires* concurrency, even if it's simulated through a timeslicing scheduler or some such. I'm pretty sure for something to be asynchronous there has to be some sort of interleaving. That's the whole point of what I just realised: there is no such interleaving within the Flex framework. Event dispatch in Flex/Flash is a *blocking* operation. There's no scheduler or anything within the event bus. Maybe your handlers will make calls to a truly asynchronous API like network calls or something, but until they make that call and return control to the code that dispatched the event, the next line of code in your event producer object will *not* execute. I'm just freaked out that I never realised this. How have my applications even been *usable* until now?!?!? Pure luck and good API design from Adobe/Macromedia. Cheers to the Player team! On Tue, Dec 9, 2008 at 03:02, Paul Andrews [EMAIL PROTECTED] wrote: They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
I'm confused. Let's clarify what we are talking about. The event dispatching is fully synchronous. If you call dispatchEvent, all event handlers are called, before the next statement is executed. Some processes (eg loading something from the backend or a timer) dispatch events in an asynchronous manner. So they call dispatchEvent at some unknown point in time I think, this is how it works. Cheers Ralf. On Tue, Dec 9, 2008 at 10:27 AM, Paul Andrews [EMAIL PROTECTED] wrote: Jules, I confess I actually misread your original post - I had anticipated that when an event is despatch it wouldn't be actioned until the current code section had been completed then the player would act upon events awaiting despatch. On the face of it, if events are despatched and all handlers invoked synchronously before the next statement runs then there's an opportunity for an unexpected race condition if handlers are updating the same data structures as the code that despatched the event. Like you I would be surprised at this behaviour and I might try and check that out for myself later today. So you are right my comments don't match your findings. I don't have a problem with the event despatcher invoking all handlers for an event in sequence - event handling has a predefined order through the display list, but there's no guarantee that multiple handlers at the same place in the hierarchy will be invoked in a set sequence. I'm somewhat surprised at your assertion that despatching an event will invoke handlers for that event synchronously - it would be interesting to get a better handle on this from someone who knows thelow-level mechanism more intimately than I do. My event handling code doesn't anticipate that despatched events are handled syncronously and as i've already said, there's always a danger of an unexpected race condition if that were true. In my previous life writing a lot of code running on multiprocessor systems we took great care to control asynchronous behaviour and to protect data structures from multiple updates using semaphores. In a faux system like the flash player, there isn't true concurrency, but if what you say is true there would be a real potential of getting an unwanted side-effect since effectively shared data structures would be open to being updated unexpectedly whenever an event is despatched. So, I'm kinda with you. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Tuesday, December 09, 2008 8:55 AM Subject: Re: [flexcoders] Parsley MVC :: some thoughts How can something be asynchronous but not concurrent? Asynchronous means that control returns from the function call immediately although the transaction triggered by the call may still be ongoing. To me, that absolutely *requires* concurrency, even if it's simulated through a timeslicing scheduler or some such. I'm pretty sure for something to be asynchronous there has to be some sort of interleaving. That's the whole point of what I just realised: there is no such interleaving within the Flex framework. Event dispatch in Flex/Flash is a *blocking* operation. There's no scheduler or anything within the event bus. Maybe your handlers will make calls to a truly asynchronous API like network calls or something, but until they make that call and return control to the code that dispatched the event, the next line of code in your event producer object will *not* execute. I'm just freaked out that I never realised this. How have my applications even been *usable* until now?!?!? Pure luck and good API design from Adobe/Macromedia. Cheers to the Player team! On Tue, Dec 9, 2008 at 03:02, Paul Andrews [EMAIL PROTECTED] wrote: They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
Hi Ralf, That's my understanding now too. What I'm slowly coming to terms with are the facts you so lucidly summarise below :) I (and I think Paul too) had always assumed that control returned from the dispatchEvent function immediately. I'm still a little bit shocked about it. In this light, dispatchEvent just routes function calls through a common object. It's too early to say whether it'll make much difference to how I code in Flex. I hate stories that end with a deus ex machina :) On Wed, Dec 10, 2008 at 02:47, Ralf Bokelberg [EMAIL PROTECTED] wrote: I'm confused. Let's clarify what we are talking about. The event dispatching is fully synchronous. If you call dispatchEvent, all event handlers are called, before the next statement is executed. Some processes (eg loading something from the backend or a timer) dispatch events in an asynchronous manner. So they call dispatchEvent at some unknown point in time I think, this is how it works. Cheers Ralf. On Tue, Dec 9, 2008 at 10:27 AM, Paul Andrews [EMAIL PROTECTED] wrote: Jules, I confess I actually misread your original post - I had anticipated that when an event is despatch it wouldn't be actioned until the current code section had been completed then the player would act upon events awaiting despatch. On the face of it, if events are despatched and all handlers invoked synchronously before the next statement runs then there's an opportunity for an unexpected race condition if handlers are updating the same data structures as the code that despatched the event. Like you I would be surprised at this behaviour and I might try and check that out for myself later today. So you are right my comments don't match your findings. I don't have a problem with the event despatcher invoking all handlers for an event in sequence - event handling has a predefined order through the display list, but there's no guarantee that multiple handlers at the same place in the hierarchy will be invoked in a set sequence. I'm somewhat surprised at your assertion that despatching an event will invoke handlers for that event synchronously - it would be interesting to get a better handle on this from someone who knows thelow-level mechanism more intimately than I do. My event handling code doesn't anticipate that despatched events are handled syncronously and as i've already said, there's always a danger of an unexpected race condition if that were true. In my previous life writing a lot of code running on multiprocessor systems we took great care to control asynchronous behaviour and to protect data structures from multiple updates using semaphores. In a faux system like the flash player, there isn't true concurrency, but if what you say is true there would be a real potential of getting an unwanted side-effect since effectively shared data structures would be open to being updated unexpectedly whenever an event is despatched. So, I'm kinda with you. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Tuesday, December 09, 2008 8:55 AM Subject: Re: [flexcoders] Parsley MVC :: some thoughts How can something be asynchronous but not concurrent? Asynchronous means that control returns from the function call immediately although the transaction triggered by the call may still be ongoing. To me, that absolutely *requires* concurrency, even if it's simulated through a timeslicing scheduler or some such. I'm pretty sure for something to be asynchronous there has to be some sort of interleaving. That's the whole point of what I just realised: there is no such interleaving within the Flex framework. Event dispatch in Flex/Flash is a *blocking* operation. There's no scheduler or anything within the event bus. Maybe your handlers will make calls to a truly asynchronous API like network calls or something, but until they make that call and return control to the code that dispatched the event, the next line of code in your event producer object will *not* execute. I'm just freaked out that I never realised this. How have my applications even been *usable* until now?!?!? Pure luck and good API design from Adobe/Macromedia. Cheers to the Player team! On Tue, Dec 9, 2008 at 03:02, Paul Andrews [EMAIL PROTECTED] wrote: They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
BUT... that dispatchEvent() call executes *synchronously*. That's always the case with Flash/Flex. Cheers Ralf. On Mon, Dec 8, 2008 at 7:49 AM, Jules Suggate [EMAIL PROTECTED] wrote: 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! 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!
Re: [flexcoders] Parsley MVC :: some thoughts
- Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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
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: flexcoders@yahoogroups.com 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
Re: [flexcoders] Parsley MVC :: some thoughts
They are asynchronous but they aren't concurrent. Paul - Original Message - From: Jules Suggate [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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
[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! 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!
