Multiple states using spaces (e.g. currentState="up default") looks nice to
the eyes.
I was thinking about impact on the transitions management - I'm not sure
that the current transition approach (fromState/toState) scales well once
we go this way.
A possible idea could be to support "state delegates", i.e. allow to break
up the MXML component in subcomponents, and let each of these subcomponents
manage its own set of states and the related transitions.
Elaborating on the Bill approach, something like:
<s:states>
<s:ExclusiveStateGroup id="mouse">
<s:State name="up"/>
<s:State name="down"/>
<s:State name="over"/>
</s:ExclusiveStateGroup>
<s:ExclusiveStateGroup id="focus" stateDelegate="focusGroup">
<s:State name="nonFocused"/>
<s:State name="focused"/>
</s:ExclusiveStateGroup>
<s:ExclusiveStateGroup id="selection">
<s:State name="nonDefault"/>
<s:State name="default"/>
</s:ExclusiveStateGroup>
</s:states>
[...]
<s:Group id="focusGroup"
top="0" bottom="0" left="0" right="0">
<s:transitions>
<s:Transition fromState"nonDefault" toState"default">
<s:Fade target="{focusRect}"
alphaFrom="0" alphaTo="1"/>
<s:/Transition>
</s:transitions>
<s:Rect id="focusRect"
top="0" bottom="0" left="0" right="0"
alpha="0" alpha.default="1"/>
<s:stroke>
<s:SolidColorStroke color="..."/>
</s:stroke>
</s:Rect>
</s:Group>
This would allow multiple transitions in each "exclusive state group" to be
managed indipendently, and make sense to me as well, because often each set
of these state groups only impacts a specific part of the component (or of
the skin): in the example, focus just add a glowing border on top of the
rest.
This allow to grab one or two set of states, and subtract them from the
cartesian multiplication (and also simplify the related transitions
management, isolating it from other states). When the "stateDelegate" is
not provided, it just means that the related states are managed by the top
MXML component.
In a sense, responding to Jude, this aims to bring the benefits of the
composition approach (versus the inheritance provided by basedOn states).
2013/6/6 Alex Harui <aha...@adobe.com>
>
>
> On 6/5/13 9:00 PM, "flexcapaci...@gmail.com" <flexcapaci...@gmail.com>
> wrote:
> Thanks for this input as well.
>
> >
> >
> >Alex, what would currentState look like as a organizing property?
> It would look like it does now. By "organizing property" I mean a
> property that you assign semantics to to change the UI. Other properties
> like isFocused and visible have well-defined semantics.
>
> >What does
> >conditional expressions look like?
> Probably like binding expressions. Or maybe they will be binding
> expressions.
> >
> >And what are you doing here with isFocused,
> >
> > <s:Rect id="focusBorder" includeIn="{isFocused}"
> > left="{emphasized ? -1 : -2}" />
> >
> >I didn't know you could use bindings in an includeIn or is that a typo?
> You can't today. I'm just imagining a world where any property can define
> whether things are included/excluded or have a different value.
> >
> >I like these:
> >
> >currentState.mouse = "up";
> >
> >currentState = "up-focused-nonDefault";
> >
> >They look like something that can be done. In this case, maybe separate
> >with spaces to promote a more CSS type of syntax? This might be simplest
> >to
> >support since it could apply properties in a last declared wins situation.
> I'm not sure I understood this section.
>
> >
> >It might also be easier to solve if CSS in Flex supported defining
> >properties such as size and position?
> FlexJS will support the CSS properties left, right, top, bottom.
> >
> >Another concrete example to think about is the toggle button. It doubles
> >the amount of states as Button just with toggled vs normal.
> I used to use ToggleButton as an example, but it doesn't have an
> emphasized state and then I think the total number of states is the same.
>
> >Right now with mobile development we have a solution for fixed size in
> >either portrait and landscape states and set the applicationDPI. We also
> >solve this with constraints and percentage based values.
> >
> >Can we or should we support responsive design can with states?
> A long-ish term goal for FlexJS is to support W3C CSS. That's because the
> browsers do already, and it is better to join them vs try to change their
> behavior. The hard part is just emulating it in Flash/Actionscript. And
> that includes a list of classNames and more media query parameters.
>
> Will that help?
> -Alex
>
>
