AFAIK:
- currently states also play a role in the skinning contract of a
skinnable component (skinStates)
- states are supported by transitions management
The first one maybe could be dropped, resulting in a "relaxed" skinning
contract: the button may have bindable "model" properties such as isFocused
or isDefault, and the skin could adjust its visuals looking at their values
(currently, MXML skin are enforced by the compiler to declare as states all
the skin states in the host component metadata - but if I remember
correctly AS skins don't have this restriction).
However, I don't know if a transition management like the current one could
be adapted to work without states.. the includeIn and property.state=...
MXML syntax allow to declare the "final value" of a property in a specified
state, but unlike a binding that would apply the value immediately, when a
transition is defined that value will only be applied at the and of the
entire transition, giving the effects a chance to provide smooth visual
changes in between. In other words, is a way to decuple the
"focusGroup.alpha" view property from the (ideal) "hostComponent.isFocused"
model property, thus allowing effects to play in between - a kind of
decoupling that could probably be achieved by defining a lot of
intermediate variables in the view layer, but the resulting code would be
ugly and hard to manage.
2013/6/6 Alex Harui <aha...@adobe.com>
> Good stuff.
>
> Today, you can sort of do this with fx:Declarations/fx:Component, but it
> isn't in-line, just in the same document. Do either of you have a skin or
> component that could truly take advantage of that?
>
> And still, you end up writing code to set currentState according to some
> other set of properties, which is why I'm wondering why you guys would
> rather manage the code that sets currentState vs just tying the visuals to
> other properties.
>
> -Alex
>
>
> On 6/6/13 3:19 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote:
>
> >Probably just a sintax choice: having them all toghether could be useful
> >to
> >quickly have an outlook of the states stuff when you open an MXML
> >document,
> >instead of searching for a number of sparse <s:states> blocks (they are
> >the
> >state of the main MXML component, after all) - on the other hand, defining
> >them inline maybe feels "right" and the resulting code snippets are more
> >manageable.
> >
> >
> >2013/6/6 jude <flexcapaci...@gmail.com>
> >
> >> Yeah. I like the state delegates. What if you took it one step further
> >>and
> >> added inline states?
> >>
> >> <s:states>
> >> <s:State name="up"/>
> >> <s:State name="down"/>
> >> <s:State name="over"/>
> >> </s:states>
> >>
> >>
> >> <s:Group id="focusGroup">
> >> <s:states>
> >> <s:State name="nonFocused"/>
> >> <s:State name="focused"/>
> >> </s:states>
> >>
> >> <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>
> >>
> >>
> >>
> >> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia <cosma...@gmail.com
> >> >wrote:
> >>
> >> > 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).
> >> >
> >> >
> >>
>
>
