The PROP_CHANGING/PROP_CHANGED event pair concept is interesting, even if I
still don't get the whole picture of how it will be working.
However, please note that I was writing thinking about possible (and
incremental) improvements the current MXML states management of Flex 4.x,
personally I don't know FlexJS well enough to be of any help - sorry but I
didn't have the chance yet to really look into it, beside reading the
messages on the list.
2013/6/6 Alex Harui <aha...@adobe.com>
> 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).
> >> >> >
> >> >> >
> >> >>
> >>
> >>
>
>
