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
