To be clear, I'm mainly concerned about how to implement this in FlexJS.
I'm not planning to try to upgrade or retrofit this into the current Flex
SDK, but someone else is certainly welcome to take that on.
My thoughts around effects in general is that, in FlexJS, you have
replaceable models. The models that will work with effects/transitions
will probably have a PROP_CHANGING/PROP_CHANGED event pair, where the
CHANGING is cancelable and would probably serve as the trigger.
On 6/6/13 9:13 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote:
>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).
>> >> >
>> >> >
>> >>
>>
>>
