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: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hall Sent: Sunday, September 03, 2006 9:02 AM To: [email protected] 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, 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 -- 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/
