6 Replies Latest reply on Feb 14, 2011 9:56 AM by Pablo Souza

    What goes in a skin and what does not.

    Gregory Lafrance Level 6

      I'm converting the Flex 3 Dashboard to Flex 4, so I'm creating a custom skin for the Pod class, which itself extends Panel.

       

      I not sure in this case what should go in the custom skin and what should go in the Pod class.

       

      When you click the minimize or maximize buttons in the Pod (Panel) title bar, the pod minimizes/maximizes/restores (if maximized).

       

      Currently the minimize/maximize code is in the Pod class (represents one pod) and the PodLayoutManager class (manages a group of pods in a view of the Dashboard TabBar).

       

      I feel like the custom skin for the Pod class (it extends Panel), which has the minimize/maximize buttons, should handle minimizing/maximizing of the pod, since the UI of the pod is being changed. Am I correct in this assumption?

       

      Also, there are a number of constants for the pod states (MINIMIZED_HEIGHT, WINDOW_STATE_DEFAULT, WINDOW_STATE_MINIMIZED, WINDOW_STATE_MAXIMIZED) that are currently in the Pod class. Should they be in the skin? The PodLayoutManager handles some aspects of pod layout.

       

      So either specifically in this case, or generally now that you have read the scenario, what should go in the skin class and what should be in the host component?

        • 1. Re: What goes in a skin and what does not.
          Pablo Souza Level 3

          Hi Gregory,

           

          You shouldn't let anything about the Pod's appearence in the Pod class. Instead let these information into skin classes.

           

           

          In the Pod class you must define the dispatched events and the skin states:

          package
          {
              [Event(name="minimizeEvent", type="flash.events.Event")]
              [Event(name="maximizeEvent", type="flash.events.Event")]
              [Event(name="modeChanged", type="flash.events.Event")]
              [SkinState("maximize")]
              [SkinState("minimize")]
              public class MyPodClass extends SkinnableContainer
              {
                  private static const MINIMIZE_EVENT:String = "minimizeEvent";
                  private static const MAXIMIZE_EVENT:String = "maximizeEvent";
                  private static const MODE_CHANGED_EVENT:String = "modeChanged";
                  
                  private static const MAXIMIZED_MODE:String = "maximized";
                  private static const MINIMIZED_MODE:String = "minimized";
                  
                  ...
                  ...
                  ...
              }
          }
          

           

           

           

          Now in the skin class you can set the Pod appearence just using the skin states:

          <!-- host component -->
          <fx:Metadata>
                  [HostComponent("MyPodClass")]
          </fx:Metadata>
          <!-- states -->
          <s:states>
                  <s:State name="minimized" />
                  <s:State name="maximized" />
                  <s:State name="disabled" />
                  <s:State name="normal" />
          </s:states>
          
          <s:Group id="collapsedContainerGroup"
                   visible.minimized="false" includeInLayout.minimized="false"
                   left="0" right="0" bottom="0" top="40">
          </s:Group>
          

           

           

          So in summary, let this constants into the Pod class:

          WINDOW_STATE_DEFAULT,

          WINDOW_STATE_MINIMIZED,

          WINDOW_STATE_MAXIMIZED

           

          The value of the constant MINIMIZED_HEIGHT should be in the skin class.

           

           

          Hope it helps you.

           

          Greets,

          Pablo Souza

          1 person found this helpful
          • 2. Re: What goes in a skin and what does not.
            Gregory Lafrance Level 6

            Thanks for your post, it does help.

             

            My situation is more complex though, because code related to minimize/maximize/restore is currently in both the Pod.as and PodLayoutManager.as classes, and its going to be a challenge to figure out what needs to be ripped out of each and placed in the skin class.

             

            What makes it more difficult is that I am writing an Adobe Flex Dev Center article on converting the Flex 3 Dashboard to Flex 4, and my word document for that article is already 33 pages (7000 words), so I think the article will probably provide highlights and the "tutorial" may be a separate PDF. We'll see what the Adobe organizers say.

             

            Anyway, if anyone else has thoughts on this, it will increase the quality of this article, which should be a good resource for you all on porting a non-trivial application to Flex 4.

            • 3. Re: What goes in a skin and what does not.
              Flex harUI Adobe Employee

              I haven't played with the Dashboard or looked at its code.  I'm not exactly

              sure what PodLayoutManager's role really is.

               

              OTOH, a Skin is only supposed to describe the visuals.  Therefore, the Pod

              class would define a set of skin parts for min/max/restore buttons and

              contain the logic that reacts to clicking those buttons.  It would also

              override getCurrentSkinState to return states reflecting whether those

              buttons got clicked.

               

              The Skin would simply define those buttons with the correct skin part IDs

              and a set of states for the controls and other visuals that map to the

              allowed states.

               

              That seems like the correct encapsulation of Pod and its skin.

               

              Now some other layout class that goes into a SkinnableContainer or Group

              that is smart about Pods is yet another encapsulation.  It should not know

              anything about min/max/restore buttons.  You can define contracts between a

              layout and the children it manages though.  For example, ScrollerLayout

              demands that its child implements an interface so we know it contains

              properties we can use to determine the scrollbar settings.

               

              There should therefore be an interface for Pods (yes, the obvious name would

              be IPod) that define some property that describes a display state

              (min/max/normal).  Pod contains the logic to maintain that property as the

              buttons get clicked, PodLayout knows how to lay them out based on that

              property.

               

              Of course, I could be completely wrong...

              1 person found this helpful
              • 4. Re: What goes in a skin and what does not.
                Gregory Lafrance Level 6

                Thanks very much for your answer Alex.

                 

                I actually was able to move forward with minimal changes, but in the process I did not follow the pattern you describe. I will try to follow your pattern as it seems to make more sense.

                 

                I moved the buttons out of the Pod and into the pod skin class, and I moved the event handler methods for the button clicks into the pod skin class as well.

                 

                Its been a great learning experience converting the Dashboard to Flex 4, and I'm not done yet, but I can move forward, so that's a good thing.

                 

                Thanks again Alex.

                • 5. Re: What goes in a skin and what does not.
                  Flex harUI Adobe Employee

                  I would not expect event handler methods in a skin.  The eventual goal for

                  Flex is to have code-less skins.  We currently have code in the skins

                  because of limitations in the platform we hope to address some day.

                   

                  I think TitleWindow and its close button might serve as a model.  The

                  handler is in TitleWindow.as, the button is defined in the skin according to

                  the skin part "contract".

                  • 6. Re: What goes in a skin and what does not.
                    Pablo Souza Level 3

                    Hey Gregory,

                     

                    I've developed a simple dashboard component using Flex 4. Take a look when you have some time http://rectius.com.br/blog/?p=713

                     

                     

                    Best regards,

                    Pablo Souza