6 Replies Latest reply on Nov 17, 2009 3:37 PM by ghempton

    fx:Binding and Skin Parts

    ghempton

      I have tried creating custom components (in mxml) with something similar to the following:

       

      [...]

       

      <fx:Binding destination="myButton.label"

                       source="outerLabel" />

       

      <fx:Script>

           <![CDATA[

       

                [...]

       

                [Bindable]

                public var outerLabel:String = "default label";

       

                [SkinPart (required="true")]

                public var myButton:Button;

       

                [...]

       

           ]]>

      </fx:Script>

       

      [...]

       

      The reason for using the Binding is to simplify the development by not requiring an overridden partAdded method. However, when I run this code, the label property is never set on myButton. I assume this is because the outerLabel property is set before the myButton property is set by the skin? Does anyone know of another way to do something like this?

       

      When I am creating non-reusable components I prefer to work inside of mxml for the advanced binding support, but to still keep the skin separate. I am looking for an elegant way to define skin parts and controller logic without having to override partAdded with a bunch of if statements (as that is pretty ugly imho).

        • 1. Re: fx:Binding and Skin Parts
          Flex harUI Adobe Employee

          Did you try adding as well as metdata to myButton?

           

          Alex Harui

          Flex SDK Developer

          Adobe Systems Inc.

          Blog: http://blogs.adobe.com/aharui

          • 2. Re: fx:Binding and Skin Parts
            ghempton Level 1

            Yeah I tried that and it didn't work. Theoretically that shouldn't make a difference anyways since it is the destination and not the source of a binding, correct?

            • 3. Re: fx:Binding and Skin Parts
              Flex harUI Adobe Employee

              Well, I suspect the problem is that the destination is changing after the binding is setup.  Components may not get created right away and so the myButton slot will be null for a bit. I was hoping that if it dispatched a change event, the binding code would be smart enough to re-compute the destination.  But I'm not surprised that didn't work.  You may have to set up the binding "later" when myButton is already created.

               

              Alex Harui

              Flex SDK Developer

              Adobe Systems Inc.

              Blog: http://blogs.adobe.com/aharui

              1 person found this helpful
              • 4. Re: fx:Binding and Skin Parts
                ghempton Level 1

                Thanks for the help Alex. I'm fairly certain you are right on why its not working.

                 

                It would be cool if there was a more declarative way to make the host components. Most of the controller logic in my components is just wiring data into skinParts, resulting in huge partAdded() methods. If this could all be done declaratively with mxml and bindings, my development process would be significantly sped up.

                • 5. Re: fx:Binding and Skin Parts
                  Flex harUI Adobe Employee

                  I reasonable suggestion, but I would argue that if your partAdded is getting too big you'll eventually suffer the performance overhead of binding.  I suppose you could have a stack of BindSetter or BindProperty calls, that might be more compact, but also not that efficient.  Maybe you can create a utility class that does the wiring.

                   

                  Alex Harui

                  Flex SDK Developer

                  Adobe Systems Inc.

                  Blog: http://blogs.adobe.com/aharui

                  • 6. Re: fx:Binding and Skin Parts
                    ghempton Level 1

                    I have yet to really hit performance issues from binding, but thanks for the heads up. I would much prefer the boost to development time by using declarative bindings at first and then optimize later.

                     

                    A utility class is an idea. One of the thing's I like about mxml is it gives you the nice declarative feel of IOC and wiring things up. Might be worthwhile to make a custom binding class which has the smarts to detect a change in a bindable destination.