4 Replies Latest reply on Apr 27, 2010 9:40 PM by -skitch-

    SDK Subclassing Components Discussion, What Do You Think?

    -skitch- Level 1

      Take this message as a blog, thought, discussion, or really whatever you feel like it should be, but I felt this should dually be noted some where within a Flex community and what better place than here.  This is a bit of a vent, or more like a "why did they do it this way"...so take it as you please.

       

      In my past, I feel that I've had the most trouble with Flex in subclassing to get my components exactly how I want them.  Mainly because some components are up to the neck in private variables/functions that simply overriding the class becomes an entirely new component that's copy and pasted (bad, very bad!) to work or look a certain way and hoping that you don't get runtime errors.

       

      For example, MenuBars are up to the teeth in private properties/functions.  The class has this dreaded private variable MARGIN_WIDTH which tags about 10 pixels of extended menubar to the ends for some reason... To actually get rid of it, you have to recreate the variable and with that comes copy and pasting the measure and updateDisplay methods.

       

      My job persists that we develop an application that is aesthetically appealing and different.  I very well agree with them and it's very rewarding to get it to work.  But hacking components to death, isn't really a long term goal if this SDK flips over like it did from AS2 to AS3.  I think most visual components should inherently have Protected all over the place instead of Private.  What are your thoughts?

       

      I came across a discussion within a Yahoo group that clarified more on why so many components are kept private and it's tagged below, definitely worth a read.

       

      Thanks,

      Skitch

      I think what he is referring to is that within the Adobe Framework it 
      is standard practice to declare event handlers in a component as
      private.

      When you (as a component developer) come to subclass the component
      and need to override the event handling functionality of the super
      class you cant as the handler is private. You can add another handler
      for the same event which is very ineffecient but in any case you cant
      stop the superclass handler from executing.

      The only exceptions to handlers being private rule seems to me where
      other Adobe dev's needed to extend a particular class and bumped in
      to this very same issue so they went and changed that particular
      super class handler to protected, lucky them!

      i.e in the framework there are 7 private and 1 protected
      mouseOverHandlers, the 1 being ListBase obviously where the DataGrid
      and Tree developer found they needed to override it.

      and to be honest, as I have said before, the "report this one
      function/var at a time" is unworkable/impractical, it needs someone
      at Adobe to take a fresh look at the whole framework from the
      perspective of a component developer. Yeah I understand component
      developers represent an insignificant blip on the radar (though maybe
      thats because the framework is so difficult to extend in the first
      place)


      Cheers!
      TGIF!


      source: http://www.mail-archive.com/flexcomponents@yahoogroups.com/msg02258.html//www.mail-archive.com/flexcomponents@yahoogroups.com/msg02258.html
        • 1. Re: SDK Subclassing Components Discussion, What Do You Think?
          Ansury Level 3

          I can agree that opening up the SDK classes much more would be beneficial (I can't stand the thought of 'monkey patching' and changing the SDK code, bleh).

           

          A different argument for this is the Java Swing API design.  Sun doesn't make much use of private methods at all.  There are some declared private, but based on the classes I looked at (Jbutton, JMenu, JList I believe) they're mostly protected or public.  (Now class attributes/variables, that's a different story, private is the norm for sure.)

          • 2. Re: SDK Subclassing Components Discussion, What Do You Think?
            -skitch- Level 1

            I like you're answer, but I'm debatable on the side of class attributes/variables always being private.  If the attribute is simply for aesthetic reasons like the Margin_Width in menubars, it really should be protected, if not public.  Or Adobe could have been nice and thrown a getter/setter in there...

            • 3. Re: SDK Subclassing Components Discussion, What Do You Think?
              David_F57 Level 5

              hi,

               

              I think the argument for the way components are written becomes less critical now that visual and functionality have been separated in spark, there is a lot more freedom in the ability to completely change a component visually and even adjust its behaviour simply by modifying a skin. Once people realise the power of the new skinning architecture I am sure we will see some incredible aesthetics and functionality and all done without the need to play with sdk behaviour or even create a custom component.

               

              David.

              • 4. Re: SDK Subclassing Components Discussion, What Do You Think?
                -skitch- Level 1

                I do agree with you David, the spark side of life is definitely looking much prettier.  The ability to set aesthetics with states is freaking sweet, but they didn't leverage all the components (hopefully soon we'll see some updates).  I'm definitely hyped about the new layout possibilities though.