Alex,
I understand exactly what you mean about testing requirements for public method
and I can really only speak to the FormItem class, but here's my experience...
The first thing I wanted to do was change where the required field asterisk is
displayed; and put it in front of the label. No big deal right. To do it all I
need to do is override updateDisplayList
and move:
// Position the "required" indicator.
displayIndicator(left, y);
left += indicatorGap;
above
// Position our label.
if (labelObj)
{...
But there are calls to about 16 private methods or values within this function
which I would have to re-write to make this work. Ironically I think all of
those would work as written if I could just call them.
--Sean
----- Original Message ----
From: Alex Harui <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, March 12, 2007 1:50:41 PM
Subject: RE: [flexcoders] Re: Are other developers hesitant to extend existing
classes in Flex?
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 weve 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:
[EMAIL PROTECTED] ups.com [mailto:flexcoders@ yahoogroups. com] On Behalf Of
Sean Sell
Sent: Friday, March 09, 2007 12:12
PM
To: [EMAIL PROTECTED] ups.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] com>
To: [EMAIL PROTECTED] ups.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, "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:[EMAIL PROTECTED]
ups.com]De la
> part de Danko Kozar
> Envoyé : jeudi 8 mars 2007 11:48
> À : [EMAIL PROTECTED]
ups.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, "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.
<!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;
}
#ygrp-vital{
background-color:#e0ecee;
margin-bottom:20px;
padding:2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size:77%;
font-family:Verdana;
font-weight:bold;
color:#333;
text-transform:uppercase;
}
#ygrp-vital ul{
padding:0;
margin:2px 0;
}
#ygrp-vital ul li{
list-style-type:none;
clear:both;
border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;
color:#ff7900;
float:right;
width:2em;
text-align:right;
padding-right:.5em;
}
#ygrp-vital ul li .cat{
font-weight:bold;
}
#ygrp-vital a {
text-decoration:none;
}
#ygrp-vital a:hover{
text-decoration:underline;
}
#ygrp-sponsor #hd{
color:#999;
font-size:77%;
}
#ygrp-sponsor #ov{
padding:6px 13px;
background-color:#e0ecee;
margin-bottom:20px;
}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;
margin:0;
}
#ygrp-sponsor #ov li{
list-style-type:square;
padding:6px 0;
font-size:77%;
}
#ygrp-sponsor #ov li a{
text-decoration:none;
font-size:130%;
}
#ygrp-sponsor #nc {
background-color:#eee;
margin-bottom:20px;
padding:0 8px;
}
#ygrp-sponsor .ad{
padding:8px 0;
}
#ygrp-sponsor .ad #hd1{
font-family:Arial;
font-weight:bold;
color:#628c2a;
font-size:100%;
line-height:122%;
}
#ygrp-sponsor .ad a{
text-decoration:none;
}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;
}
#ygrp-sponsor .ad p{
margin:0;
}
o {font-size:0;}
.MsoNormal {
margin:0 0 0 0;
}
#ygrp-text tt{
font-size:120%;
}
blockquote{margin:0 0 0 4px;}
.replbq {margin:4;}
-->
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
