Yeah, I agree there are problems with this approach and it's certainly not ideal. But listen, I wanted a Horizontal Accordion and my options were 1) wait for Adobe to make it or release a modification to the base class that allowed me to subclass the way I wanted, 2) figure out some convoluted workaround approach that allowed me to use a proper subclass that may or may not have accomplished the goal, or 3) do it fairly easily by changing a couple private variables.
So by making it myself this way I was able to get it working without too much effort, and make it visible to the community (Adobe et al) how I wanted the original Accordion component to work. This was the only workable option that I could see (and by workable I also mean sufficiently quick and easy). If I just waited for Adobe to change the base class that won't happen, somehow they've got to know what I want. I can file feature requests (which I should do more of) but I figured that enough Adobe reps read flexcoders that someone would probably see it anyway. And while it doesn't follow good coding practice, it's clean and easy to follow. If someone asks whether they should hack together a solution or wait for Adobe to release an updated component, I'll always vote for hacking something together. Let them know what you want by making it. Doug On 2/21/07, Private Romeo <[EMAIL PROTECTED]> wrote:
I believe copying code could not be the correct approach. If Adobe has not designed some of the components/classes in a way that they offer easy hooks for customization, THAT'S what needs to be changed in a future version and we should contribute to precisely define what is needed. Object oriented programming has partially been invented to support cleaner code, code reuse and clear encapsulation. "Abusing" private member variables in the inheritance chain by directly accessing them or – even worse – copying code, modifying it and inventing new types which do 99% the same but one thing slightly different results into un-maintainable code and error prone solutions. I do understand that some things might not be able to be done with the current set of components/classes/types but I'd prefer to wait for Adobe to come up with an enhanced design as opposed to creating code that ultimately needs to be rewritten someday. Just my opinion. R. *From:* [EMAIL PROTECTED] ups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Bjorn Schultheiss *Sent:* Donnerstag, 22. Februar 2007 00:31 *To:* [email protected] *Subject:* Re: [flexcoders] Are other developers hesitant to extend existing classes in Flex? D, This copy code business is nasty. Especially when your private var is 3 or 4 levels down the inheritance chain. regards, Bjorn On 22/02/2007, at 10:01 AM, Doug McCune wrote: I've had a similar experience many times, so I'll chime in with what I've been doing. The problem: you want to make a simple extension, and you see the part of the original source that you need changed or enhanced. So you try to make a subclass but you end up finding out that to do what you need done you need access to a handful of private variables and functions in the parent class. My solution: I make a cut/paste copy of the original class, name it something like OriginalClassBase.as (so like AccordionBase.as) and then I extend that new base class. What this allows me to do is make some very slight modifications to the original base class, which usually only involve changing certain variables or methods to "protected" as opposed to "private". This is bad for two reasons: 1) you're duplicating the original component in the code base, so you'll bloat the end size of your file and 2) future updates to the original class won't be included in your extended class. Problem 1 is often worth the price, since that's really the only way I can figure out to do some of the tings I want to do. And I've already resigned myself to multi-hundred kilobyte SWF files, so whatever. But if you're psycho about file size this might prevent you from taking this approach. Problem 2 I don't really see as that big a deal and here's why: the changes you're making to the base class are minor. This means that if an update comes out to the Accordion class, my copy/paste version can be compared within Eclipse using the compare functionality and I can identify exactly where the differences are. So if an update to the Accordion is released in Flex 3, then I can compare my base class with the updated Class, and either make a new base class using the Flex 3 version, or decide that I don't need to bugfixes and enhancements they rolled into Flex 3. This is just my approach. What I've found over and over again is that to really make the enhancements I want, the components simply haven't been designed quite right. This isn't to say that Adobe should have been able to anticipate every scenario that I would want to do with a subclass. Thank god they included the source for the SDK though. Doug On 2/21/07, *Dana Gutride* < [EMAIL PROTECTED]> wrote: Recently on this list, somebody said that the Flex framework team has been surprised at the resistance many developers have to subclassing and they'd like to understand it better. I'd like to put my 2 cents into this discussion because maybe we can come up with some good answers. I think the ability to extend the existing framework is fabulous, but I find that I am hesitant to subclass or extend the existing classes. Recently, I spent several days trying to override the placeSortArrow function on the datagrid. I ended up ditching my code because there were so many private variables used by the existing placeSortArrow() function that I would need to rewrite most of the datagrid.as file. I've bought books and searched online for answers, but I haven't found anything satisfactory yet. Maybe if there were more resources (even if we had to pay for them), we would find more developers extending the flex framework. Dana
