0 Replies Latest reply on Sep 27, 2010 6:39 AM by -BoNzO-

    Components with lots of states - does not scale ?

    -BoNzO- Level 2

      Following the Spark architecture, it seems quite hard to write highly customizable components with maintainable skins.

       

      As an example, we can start with spark:Panel.

       

      The default skin for this component has the following state declarations:

       

      <s:states>
         <s:State name="normal" />
         <s:State name="disabled" />
         <s:State name="normalWithControlBar" stateGroups="withControls" />
         <s:State name="disabledWithControlBar" stateGroups="withControls" />
      </s:states>

       

      If we extend Panel and add just one optional tool bar, it becomes:

       

      <skin:states>
            <s:State name="normal" />
            <s:State name="disabled" />
            <s:State name="normalWithControlBar" stateGroups="withControls" />
            <s:State name="disabledWithControlBar" stateGroups="withControls" />
            <s:State name="normalWithToolBar" stateGroups="withTools" />
            <s:State name="disabledWithToolBar" stateGroups="withTools" />
            <s:State name="normalWithControlBarAndToolBar" stateGroups="withControls, withTools" />
            <s:State name="disabledWithControlBarAndToolBar" stateGroups="withControls, withTools" />
         </skin:states>

       

      This makes us think it does not scale very well. We would like to add more runtime configuration options to our panel but that would make the number of skin state combinations skyrocket.

       

      The Spark component with most state combinations is probably VideoPlayer which has 16. In my Panel example above, it will quickly get worse than VideoPlayer since most new state will be usable with any other existing combinations. If I add another skin part I will have 16 effective skin states. If I add another one, 32... then 64...

       

      A few possible "solutions" that quickly come to mind:

       

      1)  Using simple bindings "isVisible" properties in the hostComponent and have some of the parts bind directly to that but it's not efficient as we want to remove the parts from the stage entirely.

       

      2) Use some custom AddChild declarations like in flex3. This would be very, very bad for designers wanting to modify the skins.

       

      3) Use the Flex3 approach of "template components" with IDeferredInstance, etc. Ewww, that's a step back! I would like to use Spark.

       

      Are there recommended practices or blog post mentionning how to avoid this ? I can't think of an efficient solution that would be nice for both developers and designers.

       

      Thanks for any input