I'd like to make this more concrete. Let's take Alex' Button example and
compare the 'stateGroups' way to the 'multidimensional states' way.
Here's what that Button's States might look like with 'stateGroups'.

    <s:states>
        <s:State name="up" stateGroups="upStates,normal"/>
        <s:State name="down" stateGroups="downStates,normal"/>
        <s:State name="over" stateGroups="overStates,normal"/>
        <s:State name="upAndDefault" stateGroups="upStates,default"/>
        <s:State name="downAndDefault" stateGroups="downStates,default"/>
        <s:State name="overAndDefault" stateGroups="overStates,default"/>
        <s:State name="upAndFocused" stateGroups="upStates,focused"/>
        <s:State name="downAndFocused" stateGroups="downStates,focused"/>
        <s:State name="overAndFocused" stateGroups="overStates,focused"/>
        <s:State name="upAndDefaultAndFocused"
stateGroups="upStates,default,focused"/>
        <s:State name="downAndDefaultAndFocused"
stateGroups="downStates,default,focused"/>
        <s:State name="overAndDefaultAndFocused"
stateGroups="overStates,default,focused"/>
    </s:states>

The states declaration looks heavy and is rather hard to decipher: -1

The actual component would look something like:

    <s:Rect id="focusBorder" includeIn="focused"/>
    <s:Rect id="background" color.upStates="..." color.downStates="..."
color.overStates="..."/>

Easy to read, easy to use: +1 (I know Rect doesn't have a color attribute,
but you get what I mean).
But I haven't been entirely fair: what if I want a different background
color scheme for the default states? I can't do:

    <s:Rect id="background" color.upStates="..." color.downStates="..."
color.overStates="..."
                            color.upAndDefault="..."
color.downAndDefault="..." color.overAndDefault="..."/>

That will throw a compiler exception (because 'upAndDefault' is part of
'upStates' group and thus I have a duplicate color declaration). I can fix
this, but it would require even more stateGroups, e.g. normalUpStates,
defaultUpstates, normalDownStates, etc.: -1
Or I could declare a color for every single base state, but that would be
extremely verbose and have duplicate declarations of the same color.

Conclusion: anything can be done, but it can become overly complex.


Here's what the same Button's States would look like with 'multidimensional
states':

    <s:states>
        <s:State name="up"/>
        <s:State name="down"/>
        <s:State name="over"/>
        <s:State name="focused"/>
        <s:State name="default"/>
    </s:states>

Well that's extremely terse and clear: +2

The actual component would look something like:

    <s:Rect id="focusBorder" includeIn="focused"/>
    <s:Rect id="background" color.up="..." color.down="..."
color.over="..."/>

I'm assuming a pressed default button that has focus would have its
`currenState` set to ["default", "focused", "down"].
That's still better than the 'stateGroups' way: +1

But let's see what happens with the dual color scheme. Well it can't be
done: -100
Unless we come up with something like this:

    <s:Rect id="background" color.up="..." color.down="..." color.over="..."
                            color.up.default="..." color.down.default="..."
color.over.default="..."/>

The more precise the state selector, the more precedence it takes. Doesn't
look half bad. If it can be done technically, that is.
A possible downside is that you can create situations where the developer
doesn't provide a 'required' state. For instance with this Button example,
if neither 'up', 'down' or 'over' are present in the 'currentState', the
'background' would have no color. This can be remedied, but takes careful
coding.

Conclusion: with a new syntax this approach sure looks cleaner.

I've been writing this as I was thinking about the subject, so I hope you
can make heads and tails of it ;)

Max


On Sun, Jun 2, 2013 at 1:54 PM, Arnoud Bos <arn...@artim-interactive.nl>wrote:

>
> Hi,
>
> I figure you can use some input from the community for this. I personally
> never use stategroups as i find them a bit confusing.
> So I tend to structure my components the way that it's not needed and use
> the normal straightforward states.
>
> IMHO states are one of the key features of Flex, stateGroups we can live
> without.
>
> just my 2 cents,
>
> Arnoud
>
> On 02-06-2013, at 08:49, Alex Harui <aha...@adobe.com> wrote:
>
> >> I've been coming across more and more cases where it would be great to
> >> have
> >> support for multidimensional states. What this looks like and how it's
> >> used
> >> I'm not sure. Maybe we can discuss ideas.
> > Yes, let's discuss.  I'm actually finishing up getting simple states to
> > work in FlexJS. I haven't started work on StateGroup because I wasn't
> sure
> > how often they are used and whether they are considered the "right"
> > solution by folks.
> >
>
> Met vriendelijke groet,
>
> Arnoud Bos
> Artim interactive
>
> E  arn...@artim-interactive.nl
> W  www.artim-interactive.nl
> T  +31 6 246 40 216
> A  Elisabeth Wolffstraat 77-3
>    1053TT Amsterdam
>
>
>
>
>
>

Reply via email to