[flexcoders] Re: Bubbling, Practical Use?
As an interesting side note to the discussion, wouldn't the concept of bubbling be basically obsolete in a Cairngorm based application? Here's my reasoning. If, in a pure Cairngorm app, each gesture (and event) is mapped to a specific custom command in the Controller, then bubbling has no place because each event knows exactly what it is to do and where it is to do it. Correct? -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Bubbling, Practical Use?
public static const CLICK:String = mySpecialComboBoxClick; the problem with this lies in mxml and the [Event(name)] declaration where i would assign a handler to my component in mxml then by going c:MyView mySpecialComboBoxClick=func()/ __._,_.___ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Software development tool Software development Software development services Home design software Software development company YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: Bubbling, Practical Use?
in a pure Cairngorm appain't seen one of them yet myself :) __._,_.___ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Software development tool Software development Software development services Home design software Software development company YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: Bubbling, Practical Use?
Bubbling has very few real-life applications outside of low-level mouse and keyboard events. When you have nested objects, you might not be interested that the user clicked on some tiny little graphic inside your button, you are much more interested in the fact that they clicked on the button, so that is where you listen for the event. Likewise, you might want to know that they clicked somewhere on your form, so that you can focus the form, but not have to listen for the click event on every item. The bubbling mechanism is exposed in ActionScript so that the native mouse and keyboard events are implemented transparently, without some mysterious behind-the-scenes magic. If you start adding and using custom bubbling events, things can get a little bit dangerous. I don't think there are many legitimate use cases. One danger is that a child component might dispatch a bubbling event that has the same name as an event dispatched by one of its parents. Any object listening for the event on the parent would also be notified by the event from the child. Bubbling events affect every parent of the event source, right up to the SWF root, so it's pretty much just as bad as using a root reference to store arbitrary properties and methods. Peter On 8/31/06, barry.beattie [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Say you've got a DataGrid that uses a ComboBox as an itemRenderer. You probably wouldn't want the logic that handles the change event of the CB inside that itemRenderer component, you would want it in the parent of the DataGrid Ben, please forgive my lack of Flex experiance, but can I ask why not? shouldn't the ComboBox be seen as a self-contained component that should handle all it's own stuff? it's goal is to capture a users selection, the data of which is held as public var CbSelection:String;. lets say you want to have a custom version of this that is a listbox - it has a property of mandetoryItemsSelected where 2 means that the user has to select 2 items. Surely the validation of that goes into the itemRenderer component, not the parent of the datagrid? The output of the component is a list of the two items, and the parent shouldn't care whether it's a comboBox or a group of CheckBoxes? or am I wrong? if so, please correct me. thanx barry.b -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: Bubbling, Practical Use?
I have to take issue with a few of your points. If implemented correctly, custom events can be very powerful and more flexible than other options. Bubbling has very few real-life applications outside of low-level mouse and keyboard events. Mouse and keyboard events make for a lot of real-life applications. But pretty much any time you need an ancestor to do something when its descendant changes in some way, event bubbling can be of use. Any object listening for the event on the parent would also be notified by the event from the child. Bubbling events affect every parent of the event source, right up to the SWF root, so it's pretty much just as bad as using a root reference to store arbitrary properties and methods. Isn't that what the cancelable property is for? You can (and maybe should) cancel the event at the last place you really need to listen for it. The ComboBox-as-ItemRenderer scenario is a good real-life application for custom events. Suppose I have a custom component which is based on the DataGrid. I want to keep an array of all the selected checkboxes in my DataGrid, so that I can access it later via myComponent.selectedCheckBoxes. When a ComboBox is selected, its reference will be put in the array. IMHO, it would be poor architecture to have each ComboBox target its parentDocument and put a reference to itself in that array. What if you want to nest the ComboBox more deeply at some point down the line? You have to change that parentDocument reference. With a custom event, you won't have to change anything, because it just bubbles up. Custom events also have the advantage that they are not broadcast by default from every component in your structure, which makes it easy to listen for an event from a particular component. In the above scenario, you can't just listen for click events: what if there's something else in there that can dispatch a click? You'd end up having to filter by event.target to see whether your ComboBox was the dispatcher. Instead, just dispatch a custom event from the ComboBox and listen for that custom event. Custom events can also contain any custom properties or data you would like to pass along, which can simplify the listening code greatly. Worried about name collisions? You can name your custom event anything you like - obviously you need some sort of strategy for that, but a quick pass through your class library should show you what names are already in use. I'm sure there's more to this topic - but my laptop battery's about to die. Would love to hear more. -tom -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hall Sent: Sunday, September 03, 2006 9:02 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Bubbling, Practical Use? Bubbling has very few real-life applications outside of low-level mouse and keyboard events. When you have nested objects, you might not be interested that the user clicked on some tiny little graphic inside your button, you are much more interested in the fact that they clicked on the button, so that is where you listen for the event. Likewise, you might want to know that they clicked somewhere on your form, so that you can focus the form, but not have to listen for the click event on every item. The bubbling mechanism is exposed in ActionScript so that the native mouse and keyboard events are implemented transparently, without some mysterious behind-the-scenes magic. If you start adding and using custom bubbling events, things can get a little bit dangerous. I don't think there are many legitimate use cases. One danger is that a child component might dispatch a bubbling event that has the same name as an event dispatched by one of its parents. Any object listening for the event on the parent would also be notified by the event from the child. Bubbling events affect every parent of the event source, right up to the SWF root, so it's pretty much just as bad as using a root reference to store arbitrary properties and methods. Peter On 8/31/06, barry.beattie [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Say you've got a DataGrid that uses a ComboBox as an itemRenderer. You probably wouldn't want the logic that handles the change event of the CB inside that itemRenderer component, you would want it in the parent of the DataGrid Ben, please forgive my lack of Flex experiance, but can I ask why not? shouldn't the ComboBox be seen as a self-contained component that should handle all it's own stuff? it's goal is to capture a users selection, the data of which is held as public var CbSelection:String;. lets say you want to have a custom version of this that is a listbox - it has a property of mandetoryItemsSelected where 2 means that the user has to select 2 items. Surely the validation of that goes into the itemRenderer component, not the parent of the datagrid? The output of the component is a list of the two items
Re: [flexcoders] Re: Bubbling, Practical Use?
Any object listening for the event on the parent would also be notified by the event from the child. Bubbling events affect every parent of the event source, right up to the SWF root, so it's pretty much just as bad as using a root reference to store arbitrary properties and methods. Isn't that what the cancelable property is for? You can (and maybe should) cancel the event at the last place you really need to listen for it. No. Cancelable is connected with preventDefault(), which prevents a default action from occuring when the event occurs. For example a component might automatically show an alert box when it dispatches a status event - but a handler might present the error in a different way, and call preventDefault() to stop the built-in alert from showing. You are probably thinking of stopPropagation(). This will prevent an event from bubbling past a certain point. However, you cannot do anything about the capture phase; a bubbling event will always trigger at the root and every parent in between before the target is even reached. If you were to call stopPropagation() at that point then nothing could listen for your event. (This exact technique is used with mouse events to prevent forms from being clickable, to implement modal windows). The ComboBox-as-ItemRenderer scenario is a good real-life application for custom events. Suppose I have a custom component which is based on the DataGrid. I want to keep an array of all the selected checkboxes in my DataGrid, so that I can access it later via myComponent.selectedCheckBoxes. When a ComboBox is selected, its reference will be put in the array. IMHO, it would be poor architecture to have each ComboBox target its parentDocument and put a reference to itself in that array. What if you want to nest the ComboBox more deeply at some point down the line? You have to change that parentDocument reference. With a custom event, you won't have to change anything, because it just bubbles up. The point of the cellrenderer architecture is to provide a solid framework, together with application-specific extension points. In your example, you extend DataGrid and create cellRenderers, which compose a ComboBox. By the very nature of the fact that the cellRender implements the cellrenderer interface, it knows its context and how it is being used, so there is a dependency. It is perfectly ok for this renderer to know that it is part of your specially extended DataGrid, and to use its methods. Alternatively, your extended DataGrid might know that it uses this custom cellrenderer and can coerce the type, in order to use its methods and listen to its events. In fact, depending on your needs, I would suggest one of these options is the best(tm) way. When considering architectural approaches, it is important to understand the dependencies in your code. Dependencies must exist, but they affect the way that code is reused, so your dependencies must reflect how you intend to reuse the code in the future. A common architectural blunder is to attempt to remove ALL dependencies, which results in very confusing code. In this example, we are saying that our cellRenderer is dependent on your special DataGrid, and is intended to be used in conjunction with it. Having a transparent compile-time dependency, via a class import, is far more understandable than to have a run-time dependency, based on throwing an event into the aether, and trusting it will be caught by the right receiver. In truth, by making this assumption, you have the same class dependency, but without the transparency. Custom events also have the advantage that they are not broadcast by default from every component in your structure, which makes it easy to listen for an event from a particular component. In the above scenario, you can't just listen for click events: what if there's something else in there that can dispatch a click? You'd end up having to filter by event.target to see whether your ComboBox was the dispatcher. Instead, just dispatch a custom event from the ComboBox and listen for that custom event. Custom events can also contain any custom properties or data you would like to pass along, which can simplify the listening code greatly. You do not need to sell me on the concept of custom events! :-) Custom events are absolutely fundamental to any Flex application. I am not even suggesting that custom bubbling events are fundamentally bad. I am saying that there are inherent risks with them, and that there are very few reasonable applications for them, where a different architecture couldn't solve the same problem. Most of the time that I've seen them used, it has been to cut a corner, and has resulted in less understandable code on a par with Cairngorm's global EventBroadcaster. This type of code forces you into run-time debugging far more often than when your code uses carefully considered explicit dependencies. Worried about name collisions? You can name your
RE: [flexcoders] Re: Bubbling, Practical Use?
Thanks for the reply - Yeah, I meant stopPropagation(), apologies. If I understand you correctly, you're saying that because events go through a top-down (parent-to-child) capture phase before they bubble up, it would be possible for someone to mistakenly add a capture-phase listener to the event. I'd have to agree that if you use common event names like click for your custom events you'd be likely to run into trouble. To avoid these cases, it might be helpful to create a static constant for the event type, where the constant can be named something 'normal' but its string value can be more unique: public static const CLICK:String = mySpecialComboBoxClick; Of course, then you'd basically be asking folks to only add listeners for the event by passing your developer-friendly static constant as the event type: the string itself would be too unwieldy. And you'd also be weighing the possibility that someone else happens to create a custom event type using the same cryptic string. Come to think of it, that whole scenario seems a little weird, and doesn't offer a 100% foolproof resolution to the problem. If there's another way around this, I'd love to hear it (and don't say don't use custom events ;) ). Surely there must be a way to definitively preclude the possibility of event type naming conflicts. BTW, what are some other use-cases for capture-phase event listeners? So far I have placed them in the things that can be done, but should be generally avoided category. Thanks for the discussion -tom -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hall Sent: Sunday, September 03, 2006 12:34 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Bubbling, Practical Use? Any object listening for the event on the parent would also be notified by the event from the child. Bubbling events affect every parent of the event source, right up to the SWF root, so it's pretty much just as bad as using a root reference to store arbitrary properties and methods. Isn't that what the cancelable property is for? You can (and maybe should) cancel the event at the last place you really need to listen for it. No. Cancelable is connected with preventDefault(), which prevents a default action from occuring when the event occurs. For example a component might automatically show an alert box when it dispatches a status event - but a handler might present the error in a different way, and call preventDefault() to stop the built-in alert from showing. You are probably thinking of stopPropagation(). This will prevent an event from bubbling past a certain point. However, you cannot do anything about the capture phase; a bubbling event will always trigger at the root and every parent in between before the target is even reached. If you were to call stopPropagation() at that point then nothing could listen for your event. (This exact technique is used with mouse events to prevent forms from being clickable, to implement modal windows). The ComboBox-as-ItemRenderer scenario is a good real-life application for custom events. Suppose I have a custom component which is based on the DataGrid. I want to keep an array of all the selected checkboxes in my DataGrid, so that I can access it later via myComponent.selectedCheckBoxes. When a ComboBox is selected, its reference will be put in the array. IMHO, it would be poor architecture to have each ComboBox target its parentDocument and put a reference to itself in that array. What if you want to nest the ComboBox more deeply at some point down the line? You have to change that parentDocument reference. With a custom event, you won't have to change anything, because it just bubbles up. The point of the cellrenderer architecture is to provide a solid framework, together with application-specific extension points. In your example, you extend DataGrid and create cellRenderers, which compose a ComboBox. By the very nature of the fact that the cellRender implements the cellrenderer interface, it knows its context and how it is being used, so there is a dependency. It is perfectly ok for this renderer to know that it is part of your specially extended DataGrid, and to use its methods. Alternatively, your extended DataGrid might know that it uses this custom cellrenderer and can coerce the type, in order to use its methods and listen to its events. In fact, depending on your needs, I would suggest one of these options is the best(tm) way. When considering architectural approaches, it is important to understand the dependencies in your code. Dependencies must exist, but they affect the way that code is reused, so your dependencies must reflect how you intend to reuse the code in the future. A common architectural blunder is to attempt to remove ALL dependencies, which results in very confusing code. In this example, we are saying that our cellRenderer is dependent on your special DataGrid
[flexcoders] Re: Bubbling, Practical Use?
[EMAIL PROTECTED] wrote: Say you've got a DataGrid that uses a ComboBox as an itemRenderer. You probably wouldn't want the logic that handles the change event of the CB inside that itemRenderer component, you would want it in the parent of the DataGrid Ben, please forgive my lack of Flex experiance, but can I ask why not? shouldn't the ComboBox be seen as a self-contained component that should handle all it's own stuff? it's goal is to capture a users selection, the data of which is held as public var CbSelection:String;. lets say you want to have a custom version of this that is a listbox - it has a property of mandetoryItemsSelected where 2 means that the user has to select 2 items. Surely the validation of that goes into the itemRenderer component, not the parent of the datagrid? The output of the component is a list of the two items, and the parent shouldn't care whether it's a comboBox or a group of CheckBoxes? or am I wrong? if so, please correct me. thanx barry.b -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Bubbling, Practical Use?
Any time you want to handle an event in an ancestor of where it happened. Say you've got a DataGrid that uses a ComboBox as an itemRenderer. You probably wouldn't want the logic that handles the change event of the CB inside that itemRenderer component, you would want it in the parent of the DataGrid, or higher up the chain even, because thats probably where the data lives. Bubbling lets you do that. HTH, Ben --- In flexcoders@yahoogroups.com, lostinrecursion [EMAIL PROTECTED] wrote: Hi all, I understand the concept of bubbling and know what it does with no issue. But, for some reason I can't think of a practical application of it? Could someone just give me a brief example of when bubbling might be used in a real world app? I'd appreciate it. -Kenny -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Bubbling, Practical Use?
Bubbling is helpful, because it decouples the structure of your components from the structure of your eventhandling. EG. an event emitter like a button can be nested into multiple containers but still the top container is able to receive the event. Another nice example for bubbling is loading of swfs at runtime. Your loaded swfs don't need to know the structure of the loading party, but still are able to dispatch some event to a controller like component on top of it. But you have to be careful when using bubbling. The decoupling only works with one receiver. If you add listeners in between the emitter and the receiver, you are fixing this structure and the decoupling is gone. Cheers, Ralf. On 8/29/06, ben.clinkinbeard [EMAIL PROTECTED] wrote: Any time you want to handle an event in an ancestor of where it happened. Say you've got a DataGrid that uses a ComboBox as an itemRenderer. You probably wouldn't want the logic that handles the change event of the CB inside that itemRenderer component, you would want it in the parent of the DataGrid, or higher up the chain even, because thats probably where the data lives. Bubbling lets you do that. HTH, Ben --- In flexcoders@yahoogroups.com, lostinrecursion [EMAIL PROTECTED] wrote: Hi all, I understand the concept of bubbling and know what it does with no issue. But, for some reason I can't think of a practical application of it? Could someone just give me a brief example of when bubbling might be used in a real world app? I'd appreciate it. -Kenny -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links -- Ralf Bokelberg [EMAIL PROTECTED] Flex Flash Consultant based in Cologne/Germany -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
