Coding in reusability is bad if it is not likely that the component will be reused. Unless you have the time and just want the practice.
Tracy ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Fotis Chatzinikos Sent: Friday, November 07, 2008 12:50 PM To: [email protected] Subject: Re: [flexcoders] Re: Adding data to a bubbling event Agreed, your solution (and Paul's) is more generic and clean but some times using parent is ok... you can test what kind of class the parent is and avoid any possible casting problems: if (parent is MyCustomComp) { do a } else { //we do not know this, so do nothing, throw an alert... etc } Just to complete the thread, as i mentioned earlier the previous solutions are prefereble ;-) On Fri, Nov 7, 2008 at 7:22 PM, greenfishinwater <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: Thanks for the replies, Ive been out and so was not able to respond to the replies earlier. I tend to think like Paul, and raise a second event DepartmentProduct then a third event StoreDepartmentProduct. This will keep the components more seperated. But its a pain in the A* to have to create separate events and then dispatch. Maybe it would be more convenient to pass the data into the ProductView, not as part of the Product but as a different class such as Structure, or as Pauls extendedInfo which would be more generic. The structure class would contain the department id and store id. In fact structure can be passed down through the hierarchy so that it can be added to at each new level to give data. So when the product was selected it could pass back 2 bits of data such as product id and structure. I don't like to use Parent to access the structure as when you are at the bottom, you may not know what is above you in the hierarchy. Andrew -- Fotis Chatzinikos, Ph.D. Founder, Phinnovation [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ,
