We would like to hear what you needed to change and what blocked you.
Every time we make something public or protected, we have to expand our testing time, doc time and your time to get to know the component. If we then decide we got it wrong and change it, we have more time to deprecate it, redesign it, add more tests for backward compatibility etc. This is why we've taken the conservative approach to making things public/protected. As you run into roadblocks, we like to hear what changes you were trying to make so we can find patterns in the customization attempts and provide general solutions that we feel better about supporting long-term. -Alex ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Sean Sell Sent: Friday, March 09, 2007 12:12 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? I would like to chime in on this as well. I have practically re-written the form classes to make them implement our "standard look and feel" all of this should have been able to be done via sub-classing but SO MANY private variables and functions prevented it, I basically copied and recreated all the form classes for our application what w waist, can't wait to try to update this stuff with the next version just updating them to have the hooks for automation (Flex 2.0.1) has me concerned. ----- Original Message ---- From: Gordon Smith <[EMAIL PROTECTED]> To: flexcoders@yahoogroups.com Sent: Friday, March 9, 2007 1:50:14 PM Subject: RE: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? Actually, preventDefault( ) does NOT prevent other listeners from executing; this is what stopPropagation( ) and stopImmediatePropag ation() do. preventDefault( ) simply sets the flag returned by isDefaultPrevented( ) to be true. However, some event-dispatching code in the Player or the framework is written like this (and you can do the same thing in your apps): dispatchEvent( event); if (!event.isDefaultPr evented() ) doSomethingByDefaul t(); So calling preventDefault( ) prevents doSomethingByDefaul t() from being executed. But doSomethingByDefaul t() is not a listener. - Gordon ________________________________ From: [EMAIL PROTECTED] ups.com [mailto:flexcoders@ yahoogroups. com] On Behalf Of Danko Kozar Sent: Friday, March 09, 2007 1:52 AM To: [EMAIL PROTECTED] ups.com Subject: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? Jason, this was an eye-opener! Till now I didn't realize that an event listener can cancel another listeners. But the "preventDefault( )" method of the Event class does exactly that. This is the way I should go with a PagableGrid. Thanks! --- In [EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> , "Jason Hawryluk" <[EMAIL PROTECTED]> wrote: > > As a follow up to the last response, take note of the > event.preventDefaul t(); in the handler for HEADER_RELEASE, and the fact that > I don't do a refresh on the ListCollectionView after adding the > > sort to it. > > jason > > > > > > -----Message d'origine--- -- > De : [EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> [mailto:[EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> ]De la > part de Danko Kozar > Envoyé : jeudi 8 mars 2007 11:48 > À : [EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> > Objet : [flexcoders] Re: Are other developers hesitant to extend existing > classes in Flex? > > > Private methods and variables drive me nuts.. > > For example, I'd like to make a simple DataGrid change: make headers > clickable without refreshing the grid (just toggle a sort icon). > (I need this behaviour because I'd like to have a paging DataGrid > which only propagates the sort column/direction info to a record- > feching routine on a server) > > So, I try to remove a "collection. refresh() ;" line from > the "sortByColumn( )" function, but I can't - because it's private. > > Then, I try to make a new function called "sortByColumn2" (that's a > copy of the first one, but without "refresh" stuff) and alter > the "headerReleaseHandl er" which calls it, but I can't - cause it's > private. > > And finally, I am trying to add the following code to the > constructor (yes, the constructor is public, huh.. :-)) > to "neutralize" the event listener: > > removeEventListener (DataGridEvent. HEADER_RELEASE, > headerReleaseHandle r, > false, EventPriority. DEFAULT_HANDLER) ; > > ... but I can't cause "headerReleaseHandl er" is private and can't be > seen from a subclass! > > And then, I give up.. :-) > > My conclussion is that Flex framework classes are not extensible > enough and I really can't see a reason. > Copying the whole DataGrid class and it's renderer, style, etc. > classes isn't a solution, we all agree. If not other reason - it's > not the OOP way. > > So, I'm tempted to go to a "C:\Program Files\Adobe\ Flex Builder 2 > \Flex SDK 2\frameworks\ source\mx\ " folder and make a global search > and replace on all files in this folder. You guess... > replace "private" with "protected". .. :-) > > --- In [EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> , > "Dana Gutride" <dgutride@> > 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 > > > ________________________________ Don't get soaked. Take a quick peek at the forecast with theYahoo! Search weather shortcut.
