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).
> >
> >
>
