@alex The polymer project has an interesting take on the conditionals
you're proposing.
Some examples:
https://github.com/Polymer/mdv/blob/master/examples/how_to/conditional_template.html
https://github.com/Polymer/mdv/blob/master/examples/how_to/conditional_attributes.html
On Fri, Jun 7, 2013 at 9:45 AM, Cosma Colanicchia <cosma...@gmail.com>wrote:
> 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).
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> > >>
> >
> >
>
