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