RE: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-03-09 Thread Gordon Smith
Actually, preventDefault() does NOT prevent other listeners from executing; 
this is what stopPropagation() and stopImmediatePropagation() 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.isDefaultPrevented())
doSomethingByDefault();
 
So calling preventDefault() prevents doSomethingByDefault() from being 
executed. But doSomethingByDefault() is not a listener.
 
- Gordon



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Danko 
Kozar
Sent: Friday, March 09, 2007 1:52 AM
To: flexcoders@yahoogroups.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 flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , 
Jason Hawryluk [EMAIL PROTECTED] wrote:

 As a follow up to the last response, take note of the
 event.preventDefault(); 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 : flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com  
[mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ]De la
 part de Danko Kozar
 Envoyé : jeudi 8 mars 2007 11:48
 À : flexcoders@yahoogroups.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 headerReleaseHandler 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,
 headerReleaseHandler,
 false, EventPriority.DEFAULT_HANDLER);
 
 ... but I can't cause headerReleaseHandler 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 flexcoders@yahoogroups.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
 




 


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-03-08 Thread Tom Chiverton
On Thursday 08 Mar 2007, Danko Kozar wrote:
 Private methods and variables drive me nuts..

When I did Java, I always made my private variables 'protected', but the real 
Java guys tole me that was a bad idea for some reason.

-- 
Tom Chiverton
Helping to economically enhance user-centric customers
On: http://thefalken.livejournal.com



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.com.



 Yahoo! Groups Sponsor ~-- 
Something is new at Yahoo! Groups.  Check out the enhanced email design.
http://us.click.yahoo.com/kOt0.A/gOaOAA/yQLSAA/nhFolB/TM
~- 

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


RE: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-03-08 Thread Jason Hawryluk
Danko,



See below extended datagrid and sample application to do what you want. I
realize it’s frustrating when you need to do things only to find yourself
blocked in the obvious way; but there is definitely more then one way to
skin a cat (so to speak).



I’m sure future versions of the flex framework will allow a more elegant
solutions for the day to day problems we are faced with. I too often find my
self perplexed at the reasoning to privatize certain functions and
properties; but more often then not, a work around can be found that does
not require one to rewrite the base components.



Frustration is part of the learning process. Things that seem obvious are
not always so.



Anyway, I hope the below code and sample set you on your way to
accomplishing your task.



cheers



jason

Here is the application code:

?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=http://www.adobe.com/2006/mxml; layout=absolute
xmlns:com=com.*

 com:DataGridEX  sortableColumns=true id=DGItems x=10 y=10
width=666 height=246
  mx:ArrayCollection
 mx:Object ratethis=Item 1 value=2 ratethis2=Item 1
value2=1 value3=50/
 mx:Object ratethis=Item 2 value=1 ratethis2=Item 2
value2=2 value3=120/
 mx:Object ratethis=Item 3 value=3 ratethis2=Item 3
value2=3 value3=4/
 mx:Object ratethis=Item 4 value=4 ratethis2=Item 4
value2=4 value3=5/
 mx:Object ratethis=Item 5 value=2 ratethis2=Item 5
value2=5 value3=3/
 mx:Object ratethis=Item 6 value=0 ratethis2=Item 6
value2=6 value3=0/
 mx:Object ratethis=Item 7 value=3 ratethis2=Item 7
value2=7 value3=0/
 mx:Object ratethis=Item 8 value=4 ratethis2=Item 8
value2=8 value3=4/
   mx:Object ratethis=Item 9 value=5 ratethis2=Item 9 value2=9
value3=2/
   mx:Object ratethis=Item 10 value=0 ratethis2=Item 10 value2=10
value3=3/
 /mx:ArrayCollection
  com:columns
   mx:DataGridColumn id=col1 dataField=ratethis headerText=Rate
This/
mx:DataGridColumn id=col2 dataField=value
headerText=Rating /
mx:DataGridColumn id=col3 dataField=ratethis2
headerText=Rate This 2/
mx:DataGridColumn id=col4 dataField=value2
headerText=Rating 2 /
  /com:columns
 /com:DataGridEX
/mx:Application


Here is the extended grid (place in a folder called com)

package com
{
 import mx.controls.DataGrid;
 import mx.events.DataGridEvent;
 import mx.collections.ListCollectionView;
 import mx.controls.dataGridClasses.DataGridColumn;
 import mx.collections.Sort;
 import mx.collections.SortField;

 public class DataGridEX extends DataGrid
 {

  private var collectioView:ListCollectionView;

  public function DataGridEX()
  {
   super();
   addEventListener(DataGridEvent.HEADER_RELEASE,handleSort);
  }



  private function handleSort(event:DataGridEvent):void{

   //don't let the normal sort go through
   event.preventDefault();

   var sort:Sort = new Sort();

   //get the column clicked
   var currentCol:DataGridColumn = DataGridColumn(event.itemRenderer.data);

   //reverse the current sort
   currentCol.sortDescending = !currentCol.sortDescending;

   //add the new sort to the collection so the grid can use it
   //to update the header display
   sort.fields = [new SortField(currentCol.dataField,
true,currentCol.sortDescending)];
  collectioView.sort = sort;

   //reset the colums array for our sort arrow display
   //to take effect
   columns = columns;

  }

  /**
  * override the setting of the dataprovider so we can get a
  * local listcollection set up
  **/
  override public function get dataProvider():Object
  {
   return super.dataProvider;
  }
 override public function set dataProvider(value:Object):void
 {
  super.dataProvider = value;
  collectioView = ListCollectionView(value);

 }

 }
}


  -Message d'origine-
  De : flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] la
part de Danko Kozar
  Envoyé : jeudi 8 mars 2007 11:48
  À : flexcoders@yahoogroups.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 headerReleaseHandler 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,
  headerReleaseHandler,
  false

RE: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-03-08 Thread Jason Hawryluk
As a follow up to the last response, take note of the
event.preventDefault(); 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 : flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] la
part de Danko Kozar
  Envoyé : jeudi 8 mars 2007 11:48
  À : flexcoders@yahoogroups.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 headerReleaseHandler 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,
  headerReleaseHandler,
  false, EventPriority.DEFAULT_HANDLER);

  ... but I can't cause headerReleaseHandler 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 flexcoders@yahoogroups.com, 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
  



  


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-02-22 Thread Tom Chiverton
On Thursday 22 Feb 2007, Paul DeCoursey wrote:
 support our REST based Web Services.  But also URLRequest is a final
 class and cannot be extended.

So you extend the parent, and cut and paste most of the code.
Final isn't the end of the world :-)

-- 
Tom Chiverton
Helping to continuously drive cross-platform models



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.com.



--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups - Join or create groups, clubs, forums amp; communities. Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups - Join or create groups, clubs, forums amp; 
communities. is subject to:
http://docs.yahoo.com/info/terms/
 


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-02-22 Thread Paul J DeCoursey
Tom Chiverton wrote:
 On Thursday 22 Feb 2007, Paul DeCoursey wrote:
   
 support our REST based Web Services.  But also URLRequest is a final
 class and cannot be extended.
 

 So you extend the parent, and cut and paste most of the code.
 Final isn't the end of the world :-)

   
In this case it is since the source for URLRequest is not available, 
URLRequest is a flash class not a mx class.  To make it work we would 
need to implement the entire HTTP client stack using sockets.  Not a 
small undertaking.




--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups - Join or create groups, clubs, forums amp; communities. Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups - Join or create groups, clubs, forums amp; 
communities. is subject to:
http://docs.yahoo.com/info/terms/
 


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-02-22 Thread EECOLOR

you need access to a handful of private variables and functions in the

parent class

I have extended quite some components aswell. What i found out however, was
that in the en i most of the time did not need those private variables and
methods. At the end of a day full of fiddling i found a variable or method
within the mx_internal namspace (which is publicly available).

So now when i need to extend something i make sure i check all definitions
of mx_internal first.


Greetz Erik


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-02-22 Thread Tom Chiverton
On Thursday 22 Feb 2007, Paul J DeCoursey wrote:
 In this case it is since the source for URLRequest is not available,
 URLRequest is a flash class not a mx class.  To make it work we would
 need to implement the entire HTTP client stack using sockets.  Not a
 small undertaking.

*ahh* :-)

-- 
Tom Chiverton
Helping to heterogeneously customize vertical networks



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.com.



 Yahoo! Groups Sponsor ~-- 
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/4It09A/fOaOAA/yQLSAA/nhFolB/TM
~- 

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups - Join or create groups, clubs, forums amp; communities. Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups - Join or create groups, clubs, forums amp; 
communities. is subject to:
http://docs.yahoo.com/info/terms/
 


Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex?

2007-02-22 Thread Doug McCune

If you want to say that we shouldn't rely on needing access to any private
variables, it's only a small difference to say it's OK to rely on
mx_internal variables. The internal vars are marked as such because they
might change in future releases. So if the objection is that your code might
break because Adobe releases updates to the framework class you're using,
then the same problem exists if you use the mx_internal vars.

And I agree, Adobe made design choices about what you should need access to
when you are extending components. This means they run into some of the same
coding problems if they were to try to subclass these classes as well. But
all that means is that Adobe can't make the extensions that we also can't
make. And let's remember that the choices made by the Adobe flex framework
team are just choices made by other programmers (albeit some damn good
ones), but fallible programmers nonetheless. They try to anticipate what
will be needed to make powerful extensions of components. But it's hard to
look down the road and figure out what people will want to do.

And often there is a workaround that can accomplish what you need without
accessing private vars or methods. I've gone this route as well many times.
But I think that it's not accurate to say that there is always a solution
like this. And even if you can get it to work, sometimes you end up with
such a convoluted solution, and you have to do much more processing work
(removing child components that were added, intercepting events dispatched
and stopping or redispatching...) which opens the door to more bugs.

So obviously it's a double-edged sword to ever copy-paste framework classes.
I guess it's just my personal opinion that it can be well worth it.

Doug


On 2/22/07, EECOLOR [EMAIL PROTECTED] wrote:


  you need access to a handful of private variables and functions in the
parent class

I have extended quite some components aswell. What i found out however,
was that in the en i most of the time did not need those private variables
and methods. At the end of a day full of fiddling i found a variable or
method within the mx_internal namspace (which is publicly available).

So now when i need to extend something i make sure i check all definitions
of mx_internal first.


Greetz Erik