Re: Multidimensional States

[Alex Harui]

On 6/10/13 6:53 PM, "flexcapaci...@gmail.com" 
wrote:

>I had forgot the other reason for bringing up this up but I remember it
>now.
>
>When creating mobile apps I try to support both portrait and landscape
>modes. The Flex framework has some support for this built in. When you
>switch from portrait to landscape and you have a state named "portrait" or
>"landscape" then the framework will switch to that state. However, the
>problem I run into is that I usually need to support more than those two
>states.
>
>Looking at one of my projects I have:
>
>
>
>
>
>
>
>
>
>
>
>Then I have a resize group handler that is manually handling setting the
>correct state:
>
>
>/**
> * Determines orientation
> * */
>protected function
>group1_resizeHandler(event:ResizeEvent):void
>{
>
>// get orientation
>if (height>width) {
>orientation = PORTRAIT;
>}
>else {
>orientation = LANDSCAPE;
>}
>
>
>// if on then set correct orientation
>if (currentState==PORTRAIT_ON ||
>currentState==LANDSCAPE_ON) {
>if (orientation==PORTRAIT) {
>currentState = PORTRAIT_ON;
>}
>else {
>currentState = LANDSCAPE_ON;
>}
>}
>else {
>if (orientation==LANDSCAPE) {
>currentState = LANDSCAPE_OFF;
>}
>else {
>currentState = PORTRAIT_OFF;
>}
>}
>}
>
>This is because when I had portrait and landscape defined, the framework
>would set the current state to one of those two values on orientation
>change, correct? BTW This should probably should be in getCurrentState()?
>
>I'm now aware of the basedOn property where I can inherit from the
>portrait
>or landscape state and I could have used it in my code above just as well
>as using state groups (which is more confusing to me looking back at this
>code).
FWIW, I have this vague recollection that Flex 4 states don't support
basedOn.
You might run into some issue at some point.
>
>This is the other situation I'm wondering if we can improve as well in
>this
>thread. It's really a case of, "if button.selected==true". Some sort of
>conditional branching in states.
I'm not sure I understand what you're getting at here.

>
>Alex, I'm trying to avoid binding expressions at the moment because one of
>my constraints (for personal reasons) is to keep MXML as close to pure
>vanilla XML as possible. If there are binding it is not "self contained"
>so
>to speak, meaning the compiler has to do some special processing, it has
>to
>know what a binding is.
Hmm.  Doesn't the compiler have to do some special processing for current
states syntax, event handlers and a whole lot more?  I'm curious about
what advantage there is to not using binding.

>However, I would like to see what that looks like
>if you have something.

One possibility is we use some other syntax to "bind" a property
conditionally to some other property.  I haven't looked at what characters
we could use in xml, but suppose that # is valid.

In some simple form it could be:
property#conditionalproperty

So, if a TextInput width changes in portrait vs landscape (and assume we
have a boolean property on a document called "isPortrait"


In this simple form, you have to have boolean properties on the document
for each conditional.  That means you have put more complex expressions as
booleans in your script block.  May or may not be messier than your
currentState setting logic.

Maybe it is possible to put any expression after the #.  Maybe there is
something else besides {} we should use within the quotes.

FWIW, a goal for FlexJS binding is to do more of it "in the same document"
(no more separate XXWatcherSetupUtil) and fewer anonymous functions.  I
hope to sniff out simple expressions and reduce them to more efficient
forms and evaluate them only when needed.

-Alex

Re: Multidimensional States

[jude]

I had forgot the other reason for bringing up this up but I remember it
now.

When creating mobile apps I try to support both portrait and landscape
modes. The Flex framework has some support for this built in. When you
switch from portrait to landscape and you have a state named "portrait" or
"landscape" then the framework will switch to that state. However, the
problem I run into is that I usually need to support more than those two
states.

Looking at one of my projects I have:











Then I have a resize group handler that is manually handling setting the
correct state:


/**
 * Determines orientation
 * */
protected function group1_resizeHandler(event:ResizeEvent):void
{

// get orientation
if (height>width) {
orientation = PORTRAIT;
}
else {
orientation = LANDSCAPE;
}


// if on then set correct orientation
if (currentState==PORTRAIT_ON ||
currentState==LANDSCAPE_ON) {
if (orientation==PORTRAIT) {
currentState = PORTRAIT_ON;
}
else {
currentState = LANDSCAPE_ON;
}
}
else {
if (orientation==LANDSCAPE) {
currentState = LANDSCAPE_OFF;
}
else {
currentState = PORTRAIT_OFF;
}
}
}

This is because when I had portrait and landscape defined, the framework
would set the current state to one of those two values on orientation
change, correct? BTW This should probably should be in getCurrentState()?

I'm now aware of the basedOn property where I can inherit from the portrait
or landscape state and I could have used it in my code above just as well
as using state groups (which is more confusing to me looking back at this
code).

This is the other situation I'm wondering if we can improve as well in this
thread. It's really a case of, "if button.selected==true". Some sort of
conditional branching in states.

Alex, I'm trying to avoid binding expressions at the moment because one of
my constraints (for personal reasons) is to keep MXML as close to pure
vanilla XML as possible. If there are binding it is not "self contained" so
to speak, meaning the compiler has to do some special processing, it has to
know what a binding is. However, I would like to see what that looks like
if you have something.


On Fri, Jun 7, 2013 at 3:08 AM, Maxime Cowez  wrote:

> @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  >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 
> >
> > > 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"  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
> >

Re: Multidimensional States

[Maxime Cowez]

@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 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 
>
> > 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"  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 
> > >
> > >> 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"  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  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 
> > >> >
> > >> >> Yeah. I like the state delegates. What if you took it one step
> > >>further
> > >> >>and
> > >> >> added inline states?
> > >> >>
> > >> >> 
> > >> >>   
> > >> >>  
> > >> >>  
> > >> >> 
> > >> >>
> > >> >>
> > >> >> 
> > >> >>  
> > >> >>  
> > >> >>   
> > >> >>  
> > >> >>
> > >> >>   
> > >> >>
> > >> >>  > >>alphaTo="1"/>
> > >> >>
> > >> >>
> > >> >>
> > >> >>> >> >> alpha="0" alpha.default="1"/>
> > >> >>   
> > >> >>   
> > >> >> 
> > >> >>
> > >> >>
> > >> >>
> > >> >> 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.

Re: Multidimensional States

[Cosma Colanicchia]

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 

> 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"  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 
> >
> >> 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"  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  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 
> >> >
> >> >> Yeah. I like the state delegates. What if you took it one step
> >>further
> >> >>and
> >> >> added inline states?
> >> >>
> >> >> 
> >> >>   
> >> >>  
> >> >>  
> >> >> 
> >> >>
> >> >>
> >> >> 
> >> >>  
> >> >>  
> >> >>   
> >> >>  
> >> >>
> >> >>   
> >> >>
> >> >>  >>alphaTo="1"/>
> >> >>
> >> >>
> >> >>
> >> >>>> >> alpha="0" alpha.default="1"/>
> >> >>   
> >> >>   
> >> >> 
> >> >>
> >> >>
> >> >>
> >> >> 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:
> >> >> >
> >> >> > 
> >> >> > 
> >> >> >  
> >> >> > 
> >>

Re: Multidimensional States

[Alex Harui]

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"  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 
>
>> 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"  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  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 
>> >
>> >> Yeah. I like the state delegates. What if you took it one step
>>further
>> >>and
>> >> added inline states?
>> >>
>> >> 
>> >>   
>> >>  
>> >>  
>> >> 
>> >>
>> >>
>> >> 
>> >>  
>> >>  
>> >>   
>> >>  
>> >>
>> >>   
>> >>
>> >> >alphaTo="1"/>
>> >>
>> >>
>> >>
>> >>   > >> alpha="0" alpha.default="1"/>
>> >>   
>> >>   
>> >> 
>> >>
>> >>
>> >>
>> >> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia > >> >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:
>> >> >
>> >> > 
>> >> > 
>> >> >  
>> >> > 
>> >> > 
>> >> >  
>> >> > 
>> >> >  
>> >> > 
>> >> > 
>> >> >  
>> >> > 
>> >> > 
>> >> >  
>> >> > 
>> >> >
>> >> > [...]
>> >> >
>> >> > > >> > top="0" bottom="0" left="0" right="0">
>> >> >  
>> >> > 
>> >> >  > >> > alphaFrom="0" alphaTo="1"/>
>> >> > 
>> >> >  
>> >> > > >> > top="0" bottom="0" left="0" right="0"
>> >> >  alpha="0" alpha.default="1"/>
>> >> > 
>> >> > 
>> >> >  
>> >> > 
>> >> > 
>> >> >
>> >> >
>> >> > 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
>>o

Re: Multidimensional States

[Cosma Colanicchia]

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 

> 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"  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  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 
> >
> >> Yeah. I like the state delegates. What if you took it one step further
> >>and
> >> added inline states?
> >>
> >> 
> >>   
> >>  
> >>  
> >> 
> >>
> >>
> >> 
> >>  
> >>  
> >>   
> >>  
> >>
> >>   
> >>
> >> 
> >>
> >>
> >>
> >>>> alpha="0" alpha.default="1"/>
> >>   
> >>   
> >> 
> >>
> >>
> >>
> >> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia  >> >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:
> >> >
> >> > 
> >> > 
> >> >  
> >> > 
> >> > 
> >> >  
> >> > 
> >> >  
> >> > 
> >> > 
> >> >  
> >> > 
> >> > 
> >> >  
> >> > 
> >> >
> >> > [...]
> >> >
> >> >  >> > top="0" bottom="0" left="0" right="0">
> >> >  
> >> > 
> >> >   >> > alphaFrom="0" alphaTo="1"/>
> >> > 
> >> >  
> >> >  >> > top="0" bottom="0" left="0" right="0"
> >> >  alpha="0" alpha.default="1"/>
> >> > 
> >> > 
> >> >  
> >> > 
> >> > 
> >> >
> >> >
> >> > 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).
> >> >
> >> >
> >>
>
>

Re: Multidimensional States

[Alex Harui]

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"  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  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 
>
>> Yeah. I like the state delegates. What if you took it one step further
>>and
>> added inline states?
>>
>> 
>>   
>>  
>>  
>> 
>>
>>
>> 
>>  
>>  
>>   
>>  
>>
>>   
>>
>> 
>>
>>
>>
>>   > alpha="0" alpha.default="1"/>
>>   
>>   
>> 
>>
>>
>>
>> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia > >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:
>> >
>> > 
>> > 
>> >  
>> > 
>> > 
>> >  
>> > 
>> >  
>> > 
>> > 
>> >  
>> > 
>> > 
>> >  
>> > 
>> >
>> > [...]
>> >
>> > > > top="0" bottom="0" left="0" right="0">
>> >  
>> > 
>> >  > > alphaFrom="0" alphaTo="1"/>
>> > 
>> >  
>> > > > top="0" bottom="0" left="0" right="0"
>> >  alpha="0" alpha.default="1"/>
>> > 
>> > 
>> >  
>> > 
>> > 
>> >
>> >
>> > 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).
>> >
>> >
>>

Re: Multidimensional States

[Cosma Colanicchia]

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

> Yeah. I like the state delegates. What if you took it one step further and
> added inline states?
>
> 
>   
>  
>  
> 
>
>
> 
>  
>  
>   
>  
>
>   
>
> 
>
>
>
>alpha="0" alpha.default="1"/>
>   
>   
> 
>
>
>
> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia  >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:
> >
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> >
> > [...]
> >
> >  > top="0" bottom="0" left="0" right="0">
> >  
> > 
> >   > alphaFrom="0" alphaTo="1"/>
> > 
> >  
> >  > top="0" bottom="0" left="0" right="0"
> >  alpha="0" alpha.default="1"/>
> > 
> > 
> >  
> > 
> > 
> >
> >
> > 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).
> >
> >
>

Re: Multidimensional States

[jude]

Yeah. I like the state delegates. What if you took it one step further and
added inline states?


  
 
 




 
 
  
 

  
   

   
   

  
  
  




On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia 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:
>
> 
> 
>  
> 
> 
>  
> 
>  
> 
> 
>  
> 
> 
>  
> 
>
> [...]
>
>  top="0" bottom="0" left="0" right="0">
>  
> 
>   alphaFrom="0" alphaTo="1"/>
> 
>  
>  top="0" bottom="0" left="0" right="0"
>  alpha="0" alpha.default="1"/>
> 
> 
>  
> 
> 
>
>
> 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).
>
>

Re: Multidimensional States

[jude]

On Thu, Jun 6, 2013 at 1:33 AM, Alex Harui  wrote:

>
> >
> >I like these:
> >
> >currentState.mouse = "up";
> >
> >currentState = "up-focused-nonDefault";
> >
> >They look like something that can be done. In this case, maybe separate
> >with spaces to promote a more CSS type of syntax? This might be simplest
> >to
> >support since it could apply properties in a last declared wins situation.
> I'm not sure I understood this section.
>
>
I was describing a situation where if we have multiple states and you
assign more than one state to the current state property and one state
property assignment collides with another then the last one assigned wins.
Its the same as CSS.

For example,







and

currentState = "blue emphasized";

then the label color would be green because blue and emphasized states both
define a color. There wouldn't be any error thrown.





> >
> >It might also be easier to solve if CSS in Flex supported defining
> >properties such as size and position?
> FlexJS will support the CSS properties left, right, top, bottom.
> >
> >Another concrete example to think about is the toggle button. It doubles
> >the amount of states as Button just with toggled vs normal.
> I used to use ToggleButton as an example, but it doesn't have an
> emphasized state and then I think the total number of states is the same.
>
> >Right now with mobile development we have a solution for fixed size in
> >either portrait and landscape states and set the applicationDPI. We also
> >solve this with constraints and percentage based values.
> >
> >Can we or should we support responsive design can with states?
> A long-ish term goal for FlexJS is to support W3C CSS.  That's because the
> browsers do already, and it is better to join them vs try to change their
> behavior.  The hard part is just emulating it in Flash/Actionscript.  And
> that includes a list of classNames and more media query parameters.
>

Re: Multidimensional States

[Cosma Colanicchia]

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:



 


 

 


 


 


[...]


 

 

 



 




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




2013/6/6 Alex Harui 

>
>
> On 6/5/13 9:00 PM, "flexcapaci...@gmail.com" 
> wrote:
> Thanks for this input as well.
>
> >
> >
> >Alex, what would currentState look like as a organizing property?
> It would look like it does now.  By "organizing property" I mean a
> property that you assign semantics to to change the UI.  Other properties
> like isFocused and visible have well-defined semantics.
>
> >What does
> >conditional expressions look like?
> Probably like binding expressions.  Or maybe they will be binding
> expressions.
> >
> >And what are you doing here with isFocused,
> >
> >   >left="{emphasized ? -1 : -2}" />
> >
> >I didn't know you could use bindings in an includeIn or is that a typo?
> You can't today.  I'm just imagining a world where any property can define
> whether things are included/excluded or have a different value.
> >
> >I like these:
> >
> >currentState.mouse = "up";
> >
> >currentState = "up-focused-nonDefault";
> >
> >They look like something that can be done. In this case, maybe separate
> >with spaces to promote a more CSS type of syntax? This might be simplest
> >to
> >support since it could apply properties in a last declared wins situation.
> I'm not sure I understood this section.
>
> >
> >It might also be easier to solve if CSS in Flex supported defining
> >properties such as size and position?
> FlexJS will support the CSS properties left, right, top, bottom.
> >
> >Another concrete example to think about is the toggle button. It doubles
> >the amount of states as Button just with toggled vs normal.
> I used to use ToggleButton as an example, but it doesn't have an
> emphasized state and then I think the total number of states is the same.
>
> >Right now with mobile development we have a solution for fixed size in
> >either portrait and landscape states and set the applicationDPI. We also
> >solve this with constraints and percentage based values.
> >
> >Can we or should we support responsive design can with states?
> A long-ish term goal for FlexJS is to support W3C CSS.  That's because the
> browsers do already, and it is better to join them vs try to change their
> behavior.  The hard part is just emulating it in Flash/Actionscript.  And
> that includes a list of classNames and more media query parameters.
>
> Will that help?
> -Alex
>
>

Re: Multidimensional States

[Alex Harui]

On 6/5/13 9:00 PM, "flexcapaci...@gmail.com" 
wrote:
Thanks for this input as well.

>
>
>Alex, what would currentState look like as a organizing property?
It would look like it does now.  By "organizing property" I mean a
property that you assign semantics to to change the UI.  Other properties
like isFocused and visible have well-defined semantics.

>What does
>conditional expressions look like?
Probably like binding expressions.  Or maybe they will be binding
expressions.
>
>And what are you doing here with isFocused,
>
>  left="{emphasized ? -1 : -2}" />
>
>I didn't know you could use bindings in an includeIn or is that a typo?
You can't today.  I'm just imagining a world where any property can define
whether things are included/excluded or have a different value.
>
>I like these:
>
>currentState.mouse = "up";
>
>currentState = "up-focused-nonDefault";
>
>They look like something that can be done. In this case, maybe separate
>with spaces to promote a more CSS type of syntax? This might be simplest
>to
>support since it could apply properties in a last declared wins situation.
I'm not sure I understood this section.

>
>It might also be easier to solve if CSS in Flex supported defining
>properties such as size and position?
FlexJS will support the CSS properties left, right, top, bottom.
>
>Another concrete example to think about is the toggle button. It doubles
>the amount of states as Button just with toggled vs normal.
I used to use ToggleButton as an example, but it doesn't have an
emphasized state and then I think the total number of states is the same.

>Right now with mobile development we have a solution for fixed size in
>either portrait and landscape states and set the applicationDPI. We also
>solve this with constraints and percentage based values.
>
>Can we or should we support responsive design can with states?
A long-ish term goal for FlexJS is to support W3C CSS.  That's because the
browsers do already, and it is better to join them vs try to change their
behavior.  The hard part is just emulating it in Flash/Actionscript.  And
that includes a list of classNames and more media query parameters.

Will that help?
-Alex

Re: Multidimensional States

[jude]

This became a long email. TLDR section at the end.

I went back and checked on the "inherits" property and it turns out it is
"basedOn". I don't remember seeing any documentation on this but it appears
to work:

















The third state inherits all the properties of the second state and adds
it's own.

Does this help solve anything we've discussed so far?

>From what I can tell it does but still has some problems. For example, what
if you have a state that takes styles from more than one defined state, ie
showing both the default and focused states at the same time like in your
Button example. This would be the "up-default-focused" state. The upDefault
and upFocused are both based on the "up" state. The basedOn poroperty only
lets you inherit from one.

One way to make it work is to base the combined state on the original up,
over down states and redefine the default and focused styles again (if the
state overrides a style). Or if it doesn't override a style then you would
need to add include those components in the includeIn tag like so,






















































The text.upDefaultFocused, text.overDefaultFocused, etc inline attributes
are optional in this case.

If you combined the above example with state groups you would get the
following:

Re: Multidimensional States

[Justin Mclean]

Hi,

> Side thought... will we have an Apache Flex namespace?
We already do look at the apache and experimental projects.

Justin

RE: Multidimensional States

[Kessler CTR Mark J]

Side thought... will we have an Apache Flex namespace?

-Mark

-Original Message-
From: Sebastian Mohr [mailto:flex.masul...@gmail.com] 
Sent: Tuesday, June 04, 2013 12:45 PM
To: dev@flex.apache.org
Subject: Re: Multidimensional States

+1

Replacing currentState:String with currentState:Dictionary would be nice,
but, what about downward-compatibilty?


-- 
Sebastian (PPMC)
Interaction Designer

Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample



On Mon, Jun 3, 2013 at 5:29 PM, Alex Harui  wrote:

> Good input.
>
> If I understand your scenario (and maybe you or someone can post a small
> but real-world scenario), it supports my thinking that, instead of more
> ways to use State, that the currentState property should just be thought
> of as another organizing property, and the conditional setting of values
> should be somehow determined by any property on a component, not just
> currentState.  Then if you had an orientation property or maybe
> "isLandscape" then you would create conditional expressions to determine
> what to do.
>
> -Alex
>
> On 6/3/13 8:22 AM, "Bill Turner"  wrote:
>
> >State groups are pretty much the question in reverse - they allow you to
> >group related states together, but you still have to set the currentState
> >as the combination.
> >
> >I've seen this myself mostly when trying to deal with mobile apps and the
> >rotation capabilities of a view.  If you want to use the orientation and
> >another state set, it's not as easy as it could be.
> >
> >Ultimately, I ended up doing something like Jude mentions, setting the
> >current state to a combination of the "substates":
> >
> >private var _orientation:String;// landscape or portrait
> >private var _displayAs:String:  // the "real" state
> >public function set orientation(value:String):void {
> >_orientation = value;
> >super.setCurrentState(_orientation + '_' + _displayAs);
> >}
> >
> >It would be nice if there was some way to combine the substates.  In
> >particular, in this case the built-in orientation management of the
> >mobile doesn't combine automatically, as it's checking if "landscape" and
> >"portrait" are states, so there's some workaround that's required
> >anyway...
> >
> >I had wondered about something like what Cosma suggested on the
> >declaration - but the setting of the combined states still is cumbersome
> >and requires the app to manage the sub-states itself rather than having
> >the framework help.
> >
> >Maybe something like:
> >
> >
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >
> >
> >currentState.mouse = "up"   // Change just the mouse group
> >state
> >
> >I agree that having too many substates says there's something wrong, but
> >this could help with some meaningful state combinations like orientation
> >and an app-specific state.
> >
> >Bill Turner
> >Enterprise Software Engineer
> >First Pacific Corporation
> >(503) 588-1411 ext. 2303
> >bi...@firstpac.com
> >
> >-Original Message-
> >From: John Cunliffe [mailto:mahn...@gmail.com]
> >Sent: Saturday, June 01, 2013 4:41 AM
> >To: dev@flex.apache.org
> >Subject: Re: Multidimensional States
> >
> >How is that different from the already existing
> >stateGroups<
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e
> >3d11c0bf63611-7ffa.html>property?
> >
> >
> >On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:
> >
> >> I've been coming across more and more cases where it would be great to
> >>have
> >> support for multidimensional states. What this looks like and how it's
> >>used
> >> I'm not sure. Maybe we can discuss ideas.
> >>
> ><>
> >
> >
> >
> >Confidentiality Notice: This page and any accompanying documents contain
> >information that is confidential, privileged, or exempt from disclosure
> >under applicable law and is intended for the exclusive use of the
> >addressee. This information is private and protected by law. If you are
> >not the intended recipient, you are hereby notified that any disclosure,
> >copying, distribution, or use of the contents of this information in any
> >manner is strictly prohibited.
>
>

Re: Multidimensional States

[Sebastian Mohr]

+1

Replacing currentState:String with currentState:Dictionary would be nice,
but, what about downward-compatibilty?


-- 
Sebastian (PPMC)
Interaction Designer

Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample



On Mon, Jun 3, 2013 at 5:29 PM, Alex Harui  wrote:

> Good input.
>
> If I understand your scenario (and maybe you or someone can post a small
> but real-world scenario), it supports my thinking that, instead of more
> ways to use State, that the currentState property should just be thought
> of as another organizing property, and the conditional setting of values
> should be somehow determined by any property on a component, not just
> currentState.  Then if you had an orientation property or maybe
> "isLandscape" then you would create conditional expressions to determine
> what to do.
>
> -Alex
>
> On 6/3/13 8:22 AM, "Bill Turner"  wrote:
>
> >State groups are pretty much the question in reverse - they allow you to
> >group related states together, but you still have to set the currentState
> >as the combination.
> >
> >I've seen this myself mostly when trying to deal with mobile apps and the
> >rotation capabilities of a view.  If you want to use the orientation and
> >another state set, it's not as easy as it could be.
> >
> >Ultimately, I ended up doing something like Jude mentions, setting the
> >current state to a combination of the "substates":
> >
> >private var _orientation:String;// landscape or portrait
> >private var _displayAs:String:  // the "real" state
> >public function set orientation(value:String):void {
> >_orientation = value;
> >super.setCurrentState(_orientation + '_' + _displayAs);
> >}
> >
> >It would be nice if there was some way to combine the substates.  In
> >particular, in this case the built-in orientation management of the
> >mobile doesn't combine automatically, as it's checking if "landscape" and
> >"portrait" are states, so there's some workaround that's required
> >anyway...
> >
> >I had wondered about something like what Cosma suggested on the
> >declaration - but the setting of the combined states still is cumbersome
> >and requires the app to manage the sub-states itself rather than having
> >the framework help.
> >
> >Maybe something like:
> >
> >
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >
> >
> >currentState.mouse = "up"   // Change just the mouse group
> >state
> >
> >I agree that having too many substates says there's something wrong, but
> >this could help with some meaningful state combinations like orientation
> >and an app-specific state.
> >
> >Bill Turner
> >Enterprise Software Engineer
> >First Pacific Corporation
> >(503) 588-1411 ext. 2303
> >bi...@firstpac.com
> >
> >-Original Message-
> >From: John Cunliffe [mailto:mahn...@gmail.com]
> >Sent: Saturday, June 01, 2013 4:41 AM
> >To: dev@flex.apache.org
> >Subject: Re: Multidimensional States
> >
> >How is that different from the already existing
> >stateGroups<
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e
> >3d11c0bf63611-7ffa.html>property?
> >
> >
> >On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:
> >
> >> I've been coming across more and more cases where it would be great to
> >>have
> >> support for multidimensional states. What this looks like and how it's
> >>used
> >> I'm not sure. Maybe we can discuss ideas.
> >>
> ><>
> >
> >
> >
> >Confidentiality Notice: This page and any accompanying documents contain
> >information that is confidential, privileged, or exempt from disclosure
> >under applicable law and is intended for the exclusive use of the
> >addressee. This information is private and protected by law. If you are
> >not the intended recipient, you are hereby notified that any disclosure,
> >copying, distribution, or use of the contents of this information in any
> >manner is strictly prohibited.
>
>

Re: Multidimensional States

[Alex Harui]

Good input.

If I understand your scenario (and maybe you or someone can post a small
but real-world scenario), it supports my thinking that, instead of more
ways to use State, that the currentState property should just be thought
of as another organizing property, and the conditional setting of values
should be somehow determined by any property on a component, not just
currentState.  Then if you had an orientation property or maybe
"isLandscape" then you would create conditional expressions to determine
what to do.

-Alex

On 6/3/13 8:22 AM, "Bill Turner"  wrote:

>State groups are pretty much the question in reverse - they allow you to
>group related states together, but you still have to set the currentState
>as the combination.
>
>I've seen this myself mostly when trying to deal with mobile apps and the
>rotation capabilities of a view.  If you want to use the orientation and
>another state set, it's not as easy as it could be.
>
>Ultimately, I ended up doing something like Jude mentions, setting the
>current state to a combination of the "substates":
>
>private var _orientation:String;// landscape or portrait
>private var _displayAs:String:  // the "real" state
>public function set orientation(value:String):void {
>_orientation = value;
>super.setCurrentState(_orientation + '_' + _displayAs);
>}
>
>It would be nice if there was some way to combine the substates.  In
>particular, in this case the built-in orientation management of the
>mobile doesn't combine automatically, as it's checking if "landscape" and
>"portrait" are states, so there's some workaround that's required
>anyway...
>
>I had wondered about something like what Cosma suggested on the
>declaration - but the setting of the combined states still is cumbersome
>and requires the app to manage the sub-states itself rather than having
>the framework help.
>
>Maybe something like:
>
>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>
>currentState.mouse = "up"   // Change just the mouse group
>state
>
>I agree that having too many substates says there's something wrong, but
>this could help with some meaningful state combinations like orientation
>and an app-specific state.
>
>Bill Turner
>Enterprise Software Engineer
>First Pacific Corporation
>(503) 588-1411 ext. 2303
>bi...@firstpac.com
>
>-Original Message-
>From: John Cunliffe [mailto:mahn...@gmail.com]
>Sent: Saturday, June 01, 2013 4:41 AM
>To: dev@flex.apache.org
>Subject: Re: Multidimensional States
>
>How is that different from the already existing
>stateGroups<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e
>3d11c0bf63611-7ffa.html>property?
>
>
>On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:
>
>> I've been coming across more and more cases where it would be great to
>>have
>> support for multidimensional states. What this looks like and how it's
>>used
>> I'm not sure. Maybe we can discuss ideas.
>>
><>
>
>
>
>Confidentiality Notice: This page and any accompanying documents contain
>information that is confidential, privileged, or exempt from disclosure
>under applicable law and is intended for the exclusive use of the
>addressee. This information is private and protected by law. If you are
>not the intended recipient, you are hereby notified that any disclosure,
>copying, distribution, or use of the contents of this information in any
>manner is strictly prohibited.

Re: Multidimensional States

[Alex Harui]

Hi Cosma,

Thanks for presenting this possible approach.

-Alex

On 6/3/13 12:45 AM, "Cosma Colanicchia"  wrote:

>Just trying to throw a quick thinking at it, in particular about the MXML
>declaration mess - to avoid cartesian multiplication of states, couldn't
>we
>just normalize them? I mean, grouping them in mutually exclusive groups,
>which is the typical scenario:
>
>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>
>This is different from the current freely assignable state groups, in that
>they define the mixing rules of the various base states - thus we
>implicitly expressed all the possible (and valid) combinations of the
>various base state (in this case, 3*2*2 = 12 possible valid states),
>instead of manually declaring a lot of states with long and unreadable
>names (like "overAndFocusedAndDefault").
>
>
>The API should let specify multiple current states, as long as two
>mutually
>exclusive state are not specified, for example with a sintax like this:
>
>myComp.currentState = "up-focused-nonDefault" // VALID
>myComp.currentState = "up-down-nonDefault" // INVALID
>
>(to avoid confusion with current syntax, I think we should pick another
>separator different from "," to express these "state trails") We may also
>agree that the first state declared of each exclusive group is the default
>value of its group, so that we can write:
>
>myComp.currentState = "up" // same as "up-nonFocused-nonDefault"
>
>
>Then, current state groups and MXML syntax would kick in, it should just
>recognize the state trails:
>
>
>...
>
>
>
>Or, we could also supports additional MXML like:
>
> ...
>
>In which more specific value assignment should win over more generic ones
>(something like that is already implemented, when you write alpha="0"
>alpha.over="1").
>
>
>Finally, from a compatibility point of view, a component using an
>"old-style" states set could be just translated to a single mutually
>exclusive state group (in fact, it is one) - the compiler should just
>prevent mixing the two approaches.
>
>
>
>2013/6/3 Alex Harui 
>
>> Hi Max,
>>
>> Thanks for detailing it out.
>>
>> In the relatively few minutes I've spent thinking about the problem, I
>> pondered whether the answer is to expand on how s:State is used, or
>>simply
>> allow you to have conditional attributes based on things other than
>> States.  IMO, along with this set of States is code you have to write to
>> set currentState appropriately, and in many cases, it seems like you're
>> just going to wire it to some other property.  For this Button example,
>>we
>> don't really have a "isFocused" property, but we certainly could add
>>one,
>> and the "Default" states are all tied to what is currently called the
>> 'emphasized' property.  So why not some syntax that just lets you set a
>> property based on some other property?  For sure there can be
>>collisions,
>> or maybe it won't handle complex situations, but it seems like when I
>>look
>> at the AS that we write when we give up on States, they are generally
>> simple expressions.  So, while property.state implies the value of that
>> property when currentState is that State, maybe some other delimiter
>> besides '.' can be used to dictate the value of a property when some
>>other
>> property is true or false or some simple expression.  I'm going to use
>>"("
>> in this example, which may not be legal XML, but should give you an
>>idea)
>>
>> Then the states are simply:
>>
>> 
>>   
>>   
>>   
>> 
>>
>> And some widgets in the skin look like:
>>
>>
>> > left(emphasized)=-2 left=-1 />
>> > color(currentState=="up"&&emphasized)
>>
>> Now, when I look at that, I wonder: why not just use binding?
>>
>> > left="{emphasized ? -1 : -2}" />
>> > color="{(currentState=="up"&&emphasized) ? "red" : "blue"}"
>>
>> Yes, I know we told you not to use binding in skins for performance
>> reasons, but I am hoping to find ways to make databinding much faster in
>> FlexJS.
>>
>>
>>
>> And one final thought:  In FlexJS, we may end up saying that you
>>shouldn't
>> specify these visual aspects in the "skin".  Instead, you might want to
>> use more CSS, and then we could implement attribute selectors on the AS
>> side since that CSS is going to work on the JS side.
>>
>> Then you just have:
>>
>> > >
>>
>> And CSS like:
>>
>> .buttonFocusBorder#focusBorder[emphasized] {
>>   left: -2;
>> }
>> .buttonFocusBorder#focusBorder {
>>   left: -1;
>> }
>>
>> .buttonBackground#background[emphasize] {
>>   color: "blue";
>> }
>>
>> .buttonBackground#background {
>>   color: "red";
>> }
>>
>> I'm not sure we can extend the set of attributes or not, but we can also
>> specify multiple class selector names, so we might be able to handle
>> custom properties that way.
>>
>>
>> -Alex
>>
>> On 6/2/13 10:45 AM, "Maxime Cowez"  wrote:
>>
>> >I'd like to make this more concrete. Let's take Alex' Button example
>>and

RE: Multidimensional States

[Bill Turner]

State groups are pretty much the question in reverse - they allow you to group 
related states together, but you still have to set the currentState as the 
combination.

I've seen this myself mostly when trying to deal with mobile apps and the 
rotation capabilities of a view.  If you want to use the orientation and 
another state set, it's not as easy as it could be.

Ultimately, I ended up doing something like Jude mentions, setting the current 
state to a combination of the "substates":

private var _orientation:String;// landscape or portrait
private var _displayAs:String:  // the "real" state
public function set orientation(value:String):void {
_orientation = value;
super.setCurrentState(_orientation + '_' + _displayAs);
}

It would be nice if there was some way to combine the substates.  In 
particular, in this case the built-in orientation management of the mobile 
doesn't combine automatically, as it's checking if "landscape" and "portrait" 
are states, so there's some workaround that's required anyway...

I had wondered about something like what Cosma suggested on the declaration - 
but the setting of the combined states still is cumbersome and requires the app 
to manage the sub-states itself rather than having the framework help.

Maybe something like:


  
  
  
  
  
  
  
  
  
  
  
  
  


currentState.mouse = "up"   // Change just the mouse group state

I agree that having too many substates says there's something wrong, but this 
could help with some meaningful state combinations like orientation and an 
app-specific state.

Bill Turner
Enterprise Software Engineer
First Pacific Corporation
(503) 588-1411 ext. 2303
bi...@firstpac.com

-Original Message-
From: John Cunliffe [mailto:mahn...@gmail.com]
Sent: Saturday, June 01, 2013 4:41 AM
To: dev@flex.apache.org
Subject: Re: Multidimensional States

How is that different from the already existing
stateGroups<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf63611-7ffa.html>property?


On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:

> I've been coming across more and more cases where it would be great to have
> support for multidimensional states. What this looks like and how it's used
> I'm not sure. Maybe we can discuss ideas.
>
<>



Confidentiality Notice: This page and any accompanying documents contain 
information that is confidential, privileged, or exempt from disclosure under 
applicable law and is intended for the exclusive use of the addressee. This 
information is private and protected by law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the contents of this information in any manner is strictly prohibited.

Re: Multidimensional States

[Cosma Colanicchia]

Just trying to throw a quick thinking at it, in particular about the MXML
declaration mess - to avoid cartesian multiplication of states, couldn't we
just normalize them? I mean, grouping them in mutually exclusive groups,
which is the typical scenario:


  
  
  
  
  
  
  
  
  
  
  
  
  


This is different from the current freely assignable state groups, in that
they define the mixing rules of the various base states - thus we
implicitly expressed all the possible (and valid) combinations of the
various base state (in this case, 3*2*2 = 12 possible valid states),
instead of manually declaring a lot of states with long and unreadable
names (like "overAndFocusedAndDefault").


The API should let specify multiple current states, as long as two mutually
exclusive state are not specified, for example with a sintax like this:

myComp.currentState = "up-focused-nonDefault" // VALID
myComp.currentState = "up-down-nonDefault" // INVALID

(to avoid confusion with current syntax, I think we should pick another
separator different from "," to express these "state trails") We may also
agree that the first state declared of each exclusive group is the default
value of its group, so that we can write:

myComp.currentState = "up" // same as "up-nonFocused-nonDefault"


Then, current state groups and MXML syntax would kick in, it should just
recognize the state trails:


...



Or, we could also supports additional MXML like:

 ...

In which more specific value assignment should win over more generic ones
(something like that is already implemented, when you write alpha="0"
alpha.over="1").


Finally, from a compatibility point of view, a component using an
"old-style" states set could be just translated to a single mutually
exclusive state group (in fact, it is one) - the compiler should just
prevent mixing the two approaches.



2013/6/3 Alex Harui 

> Hi Max,
>
> Thanks for detailing it out.
>
> In the relatively few minutes I've spent thinking about the problem, I
> pondered whether the answer is to expand on how s:State is used, or simply
> allow you to have conditional attributes based on things other than
> States.  IMO, along with this set of States is code you have to write to
> set currentState appropriately, and in many cases, it seems like you're
> just going to wire it to some other property.  For this Button example, we
> don't really have a "isFocused" property, but we certainly could add one,
> and the "Default" states are all tied to what is currently called the
> 'emphasized' property.  So why not some syntax that just lets you set a
> property based on some other property?  For sure there can be collisions,
> or maybe it won't handle complex situations, but it seems like when I look
> at the AS that we write when we give up on States, they are generally
> simple expressions.  So, while property.state implies the value of that
> property when currentState is that State, maybe some other delimiter
> besides '.' can be used to dictate the value of a property when some other
> property is true or false or some simple expression.  I'm going to use "("
> in this example, which may not be legal XML, but should give you an idea)
>
> Then the states are simply:
>
> 
>   
>   
>   
> 
>
> And some widgets in the skin look like:
>
>
>  left(emphasized)=-2 left=-1 />
>  color(currentState=="up"&&emphasized)
>
> Now, when I look at that, I wonder: why not just use binding?
>
>  left="{emphasized ? -1 : -2}" />
>  color="{(currentState=="up"&&emphasized) ? "red" : "blue"}"
>
> Yes, I know we told you not to use binding in skins for performance
> reasons, but I am hoping to find ways to make databinding much faster in
> FlexJS.
>
>
>
> And one final thought:  In FlexJS, we may end up saying that you shouldn't
> specify these visual aspects in the "skin".  Instead, you might want to
> use more CSS, and then we could implement attribute selectors on the AS
> side since that CSS is going to work on the JS side.
>
> Then you just have:
>
>  
>
> And CSS like:
>
> .buttonFocusBorder#focusBorder[emphasized] {
>   left: -2;
> }
> .buttonFocusBorder#focusBorder {
>   left: -1;
> }
>
> .buttonBackground#background[emphasize] {
>   color: "blue";
> }
>
> .buttonBackground#background {
>   color: "red";
> }
>
> I'm not sure we can extend the set of attributes or not, but we can also
> specify multiple class selector names, so we might be able to handle
> custom properties that way.
>
>
> -Alex
>
> On 6/2/13 10:45 AM, "Maxime Cowez"  wrote:
>
> >I'd like to make this more concrete. Let's take Alex' Button example and
> >compare the 'stateGroups' way to the 'multidimensional states' way.
> >Here's what that Button's States might look like with 'stateGroups'.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >stateGroups="upSta

Re: Multidimensional States

[Alex Harui]

Hi Max,

Thanks for detailing it out.

In the relatively few minutes I've spent thinking about the problem, I
pondered whether the answer is to expand on how s:State is used, or simply
allow you to have conditional attributes based on things other than
States.  IMO, along with this set of States is code you have to write to
set currentState appropriately, and in many cases, it seems like you're
just going to wire it to some other property.  For this Button example, we
don't really have a "isFocused" property, but we certainly could add one,
and the "Default" states are all tied to what is currently called the
'emphasized' property.  So why not some syntax that just lets you set a
property based on some other property?  For sure there can be collisions,
or maybe it won't handle complex situations, but it seems like when I look
at the AS that we write when we give up on States, they are generally
simple expressions.  So, while property.state implies the value of that
property when currentState is that State, maybe some other delimiter
besides '.' can be used to dictate the value of a property when some other
property is true or false or some simple expression.  I'm going to use "("
in this example, which may not be legal XML, but should give you an idea)

Then the states are simply:


  
  
  


And some widgets in the skin look like:




 wrote:

>I'd like to make this more concrete. Let's take Alex' Button example and
>compare the 'stateGroups' way to the 'multidimensional states' way.
>Here's what that Button's States might look like with 'stateGroups'.
>
>
>
>
>
>
>
>
>
>
>
>stateGroups="upStates,default,focused"/>
>stateGroups="downStates,default,focused"/>
>stateGroups="overStates,default,focused"/>
>
>
>The states declaration looks heavy and is rather hard to decipher: -1
>
>The actual component would look something like:
>
>
>color.overStates="..."/>
>
>Easy to read, easy to use: +1 (I know Rect doesn't have a color attribute,
>but you get what I mean).
>But I haven't been entirely fair: what if I want a different background
>color scheme for the default states? I can't do:
>
>color.overStates="..."
>color.upAndDefault="..."
>color.downAndDefault="..." color.overAndDefault="..."/>
>
>That will throw a compiler exception (because 'upAndDefault' is part of
>'upStates' group and thus I have a duplicate color declaration). I can fix
>this, but it would require even more stateGroups, e.g. normalUpStates,
>defaultUpstates, normalDownStates, etc.: -1
>Or I could declare a color for every single base state, but that would be
>extremely verbose and have duplicate declarations of the same color.
>
>Conclusion: anything can be done, but it can become overly complex.
>
>
>Here's what the same Button's States would look like with
>'multidimensional
>states':
>
>
>
>
>
>
>
>
>
>Well that's extremely terse and clear: +2
>
>The actual component would look something like:
>
>
>color.over="..."/>
>
>I'm assuming a pressed default button that has focus would have its
>`currenState` set to ["default", "focused", "down"].
>That's still better than the 'stateGroups' way: +1
>
>But let's see what happens with the dual color scheme. Well it can't be
>done: -100
>Unless we come up with something like this:
>
>color.over="..."
>color.up.default="..."
>color.down.default="..."
>color.over.default="..."/>
>
>The more precise the state selector, the more precedence it takes. Doesn't
>look half bad. If it can be done technically, that is.
>A possible downside is that you can create situations where the developer
>doesn't provide a 'required' state. For instance with this Button example,
>if neither 'up', 'down' or 'over' are present in the 'currentState', the
>'background' would have no color. This can be remedied, but takes careful
>coding.
>
>Conclusion: with a new syntax this approach sure looks cleaner.
>
>I've been writing this as I was thinking about the subject, so I hope you
>can make heads and tails of it ;)
>
>Max
>
>
>On Sun, Jun 2, 2013 at 1:54 PM, Arnoud Bos
>wrote:
>
>>
>> Hi,
>>
>> I figure you can use some input from the community for this. I
>>personally
>> never use stategroups as i find them a bit confusing.
>> So I tend to structure my components the way that it's not needed and
>>use
>> the normal straightforward states.
>>
>> IMHO states are one of the key features of Flex, stateGroups we can live
>> without.
>>
>> just my 2 cents,
>>
>> Arnoud
>>
>> On 02-06-2013, at 08:49, Alex Harui  wrote:
>>
>> >> I've been coming across more and more cases where it would be great
>>to
>> >> have
>> >> support for multidimensional states. What this looks like and how
>>it's
>> >> used
>> >> I'm not sure. Maybe we can discuss ideas.
>> > Yes, let's discuss.  I'm

Re: Multidimensional States

[Maxime Cowez]

I'd like to make this more concrete. Let's take Alex' Button example and
compare the 'stateGroups' way to the 'multidimensional states' way.
Here's what that Button's States might look like with 'stateGroups'.
















The states declaration looks heavy and is rather hard to decipher: -1

The actual component would look something like:




Easy to read, easy to use: +1 (I know Rect doesn't have a color attribute,
but you get what I mean).
But I haven't been entirely fair: what if I want a different background
color scheme for the default states? I can't do:



That will throw a compiler exception (because 'upAndDefault' is part of
'upStates' group and thus I have a duplicate color declaration). I can fix
this, but it would require even more stateGroups, e.g. normalUpStates,
defaultUpstates, normalDownStates, etc.: -1
Or I could declare a color for every single base state, but that would be
extremely verbose and have duplicate declarations of the same color.

Conclusion: anything can be done, but it can become overly complex.


Here's what the same Button's States would look like with 'multidimensional
states':









Well that's extremely terse and clear: +2

The actual component would look something like:




I'm assuming a pressed default button that has focus would have its
`currenState` set to ["default", "focused", "down"].
That's still better than the 'stateGroups' way: +1

But let's see what happens with the dual color scheme. Well it can't be
done: -100
Unless we come up with something like this:



The more precise the state selector, the more precedence it takes. Doesn't
look half bad. If it can be done technically, that is.
A possible downside is that you can create situations where the developer
doesn't provide a 'required' state. For instance with this Button example,
if neither 'up', 'down' or 'over' are present in the 'currentState', the
'background' would have no color. This can be remedied, but takes careful
coding.

Conclusion: with a new syntax this approach sure looks cleaner.

I've been writing this as I was thinking about the subject, so I hope you
can make heads and tails of it ;)

Max


On Sun, Jun 2, 2013 at 1:54 PM, Arnoud Bos wrote:

>
> Hi,
>
> I figure you can use some input from the community for this. I personally
> never use stategroups as i find them a bit confusing.
> So I tend to structure my components the way that it's not needed and use
> the normal straightforward states.
>
> IMHO states are one of the key features of Flex, stateGroups we can live
> without.
>
> just my 2 cents,
>
> Arnoud
>
> On 02-06-2013, at 08:49, Alex Harui  wrote:
>
> >> I've been coming across more and more cases where it would be great to
> >> have
> >> support for multidimensional states. What this looks like and how it's
> >> used
> >> I'm not sure. Maybe we can discuss ideas.
> > Yes, let's discuss.  I'm actually finishing up getting simple states to
> > work in FlexJS. I haven't started work on StateGroup because I wasn't
> sure
> > how often they are used and whether they are considered the "right"
> > solution by folks.
> >
>
> Met vriendelijke groet,
>
> Arnoud Bos
> Artim interactive
>
> E  arn...@artim-interactive.nl
> W  www.artim-interactive.nl
> T  +31 6 246 40 216
> A  Elisabeth Wolffstraat 77-3
>1053TT Amsterdam
>
>
>
>
>
>

Re: Multidimensional States

[Arnoud Bos]

Hi,

I figure you can use some input from the community for this. I personally never 
use stategroups as i find them a bit confusing.
So I tend to structure my components the way that it's not needed and use the 
normal straightforward states.

IMHO states are one of the key features of Flex, stateGroups we can live 
without.

just my 2 cents,

Arnoud

On 02-06-2013, at 08:49, Alex Harui  wrote:

>> I've been coming across more and more cases where it would be great to
>> have
>> support for multidimensional states. What this looks like and how it's
>> used
>> I'm not sure. Maybe we can discuss ideas.
> Yes, let's discuss.  I'm actually finishing up getting simple states to
> work in FlexJS. I haven't started work on StateGroup because I wasn't sure
> how often they are used and whether they are considered the "right"
> solution by folks.
> 

Met vriendelijke groet,

Arnoud Bos
Artim interactive

E  arn...@artim-interactive.nl
W  www.artim-interactive.nl
T  +31 6 246 40 216
A  Elisabeth Wolffstraat 77-3
   1053TT Amsterdam

Re: Multidimensional States

[Alex Harui]

On 6/1/13 3:28 AM, "flexcapaci...@gmail.com" 
wrote:

>I've been coming across more and more cases where it would be great to
>have
>support for multidimensional states. What this looks like and how it's
>used
>I'm not sure. Maybe we can discuss ideas.
Yes, let's discuss.  I'm actually finishing up getting simple states to
work in FlexJS. I haven't started work on StateGroup because I wasn't sure
how often they are used and whether they are considered the "right"
solution by folks.
>
>I'd really like to know what the Flex team was
>talking about when they mentioned this.
It wasn't the "Flex team", it was just me.  Before we get into proposals,
I'd like to collect a set of scenarios, so we have something concrete to
apply the proposals to.

The only time I think I ran into this was with Button.  A standard push
button in Flex (and other OS's) changes its look not only on
up/down/hover/disabled, but also whether it is the "default" button for a
form, and then again when it has focus.  Things like focus visuals in
current Flex are not applied via states for the reason that it exploded
the number of skin states the designer would have to create, and I think
that StateGroups weren't up to the challenge either.  There is another
case involving Panel.

For Button, if you want to specify the focus appearance in the "skin" as
well, you end up with the following states (not including disabled states):

Up
Down
Over
UpAndDefault
DownAndDefault
OverAndDefault
UpAndFocused
DownAndFocused
OverAndFocused
UpAndDefaultAndFocused
DownAndDefaultAndFocused
OverAndDefaultAndFocused

The focused appearance is often different between UpAndFocused and
UpAndDefaultAndFocused, so I don't think a StateGroup applies well, and
the focused appearance may not change between Up/Down/Over.  But maybe
there is a way to make StateGroup work here.

For Panel, I think if you look in PanelSkin you see code in
updateDisplayList that considers borderVisible and sets content offsets.
A lot of the code in the skins are a "punt" on states.  States would have
allowed declarative, non-code ways of describing all of the visuals, but I
think it would have exploded as well.  Panel would have states like:

Normal
Disabled
NormalWithControlBar
DisabledWithControlBar
NormalWithBorder
DisabledWithBorder
NormalWithBorderAndControlBar
DisabledWithBorderAndControlBar

I don't have a proposal ready to go.  I was thinking of something called
"conditionals" which I think are just binding statements.  Then for Panel
you could just say contents.borderVisible or something like that.   I'm
not clear that property.state syntax would work or needs to work for
multidimensional states, but I'm open to it.  One "constraint" for FlexJS
right now is that we're trying to get FB and the old MXMLC compiler to
compile your app cleanly so adding other property.state possibilities
without the appropriate mx:State will result in errors and be more work to
implement.  Maybe some other delimiter?  Maybe implement attribute
selectors in CSS?

So, if you can offer up a scenario, then we can see whether StateGroup is
the right answer or if we can come up with something else.

Thanks,
-Alex

Re: Multidimensional States

[Maxime Cowez]

When I find myself pondering such a situation, I usually come to the
conclusion it's time to split up my component into smaller ones: most of
the times it's a signal that there's too much going in one view and I'm
breaking "separation of concerns".
Of course that's not true for *every* situation, but for those other cases
stateGroups usually work fine (though admittedly they can sometimes become
a bit unwieldy).
That said, I'm not against the idea, but losing support for setting state
dependant values inline would be absolutely unacceptable to me. To me
that's one of the best features that came with Flex 4. (I also wouldn't
call that backwards compatible since it would break nearly every single
view component I have ever written).

Max


On Sat, Jun 1, 2013 at 4:16 PM, Jonathan Campos wrote:

> Usually I solve this by just overriding the getCurrentState method and a
> having all the posible options in the  group.
>
> J
>
>
> On Sat, Jun 1, 2013 at 6:41 AM, John Cunliffe  wrote:
>
> > How is that different from the already existing
> > stateGroups<
> >
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf63611-7ffa.html
> > >property?
> >
> >
> > On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:
> >
> > > I've been coming across more and more cases where it would be great to
> > have
> > > support for multidimensional states. What this looks like and how it's
> > used
> > > I'm not sure. Maybe we can discuss ideas.
> > >
> > > Alex wrote on the FlexJS wiki page,
> > >
> > > *States were used often but had a limitation once the set of states you
> > > wanted started having "dimensions". For example, the Flex default
> button
> > > has an emphasized state, which adds to the selected state to create a
> lot
> > > of potential skin states. And when we considered having this same
> button
> > > show a focused state, it got unwieldy so we didn't do it. We never got
> > > around to doing multi-dimensional states, but now it is time to try
> since
> > > we can break backward compatibility if we have to. *[0]
> > >
> > > I have a couple of suggestions. The first is to create a new State
> class
> > > that you could add to your declarations and add more states into it. It
> > > would look something like this:
> > >
> > > 
> > >
> > > 
> > > 
> > >
> > >
> > >
> > >
> > > 
> > >
> > >
> > > 
> > > 
> > >
> > >
> > > 
> > > 
> > >   property="isAuthenticated"
> > > value="true"/>
> > > 
> > > 
> > > 
> > > 
> > >   property="isAuthenticated"
> > > value="false"/>
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > 
> > >
> > > 
> > >
> > >
> > > You would use it like this, loginStateGroup.currentState = "loggedIn".
> > >
> > > I think this would be the easiest way to add more support. It would use
> > the
> > > same syntax we already know. It would also be backwards compatible. The
> > > disadvantages of this would be the lack of support of using states
> > inline.
> > > So the compiler wouldn't recognize things like this,
> > >
> > > .
> > >
> > > This second example might be more closely related to the original idea,
> > >
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > And you would assign it like this,
> > >
> > > currentState = "state3_RedState";
> > >
> > > or,
> > >
> > > currentState = ["state3", "redState"]; // if renamed to redState
> > >
> > > The nested state would inherit the properties of the parent state. The
> > > thing is there is an inherit property already on the State class. In
> > Flex 3
> > > we had support for a base state and inheritance. So maybe there's some
> > > support for this already. I'd really like to know what the Flex team
> was
> > > talking about when they mentioned this.
> > >
> > > Jude
> > >
> > >
> > >
> > >
> > > [0] -
> > >
> >
> https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype
> > >
> >
>
>
>
> --
> Jonathan Campos
>

Re: Multidimensional States

[Jonathan Campos]

Usually I solve this by just overriding the getCurrentState method and a
having all the posible options in the  group.

J


On Sat, Jun 1, 2013 at 6:41 AM, John Cunliffe  wrote:

> How is that different from the already existing
> stateGroups<
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf63611-7ffa.html
> >property?
>
>
> On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:
>
> > I've been coming across more and more cases where it would be great to
> have
> > support for multidimensional states. What this looks like and how it's
> used
> > I'm not sure. Maybe we can discuss ideas.
> >
> > Alex wrote on the FlexJS wiki page,
> >
> > *States were used often but had a limitation once the set of states you
> > wanted started having "dimensions". For example, the Flex default button
> > has an emphasized state, which adds to the selected state to create a lot
> > of potential skin states. And when we considered having this same button
> > show a focused state, it got unwieldy so we didn't do it. We never got
> > around to doing multi-dimensional states, but now it is time to try since
> > we can break backward compatibility if we have to. *[0]
> >
> > I have a couple of suggestions. The first is to create a new State class
> > that you could add to your declarations and add more states into it. It
> > would look something like this:
> >
> > 
> >
> > 
> > 
> >
> >
> >
> >
> > 
> >
> >
> > 
> > 
> >
> >
> > 
> > 
> >   > value="true"/>
> > 
> > 
> > 
> > 
> >   > value="false"/>
> > 
> > 
> > 
> > 
> > 
> >
> >
> > 
> >
> > 
> >
> >
> > You would use it like this, loginStateGroup.currentState = "loggedIn".
> >
> > I think this would be the easiest way to add more support. It would use
> the
> > same syntax we already know. It would also be backwards compatible. The
> > disadvantages of this would be the lack of support of using states
> inline.
> > So the compiler wouldn't recognize things like this,
> >
> > .
> >
> > This second example might be more closely related to the original idea,
> >
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > And you would assign it like this,
> >
> > currentState = "state3_RedState";
> >
> > or,
> >
> > currentState = ["state3", "redState"]; // if renamed to redState
> >
> > The nested state would inherit the properties of the parent state. The
> > thing is there is an inherit property already on the State class. In
> Flex 3
> > we had support for a base state and inheritance. So maybe there's some
> > support for this already. I'd really like to know what the Flex team was
> > talking about when they mentioned this.
> >
> > Jude
> >
> >
> >
> >
> > [0] -
> >
> https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype
> >
>



-- 
Jonathan Campos

Re: Multidimensional States

[John Cunliffe]

How is that different from the already existing
stateGroupsproperty?


On Sat, Jun 1, 2013 at 12:28 PM, jude  wrote:

> I've been coming across more and more cases where it would be great to have
> support for multidimensional states. What this looks like and how it's used
> I'm not sure. Maybe we can discuss ideas.
>
> Alex wrote on the FlexJS wiki page,
>
> *States were used often but had a limitation once the set of states you
> wanted started having "dimensions". For example, the Flex default button
> has an emphasized state, which adds to the selected state to create a lot
> of potential skin states. And when we considered having this same button
> show a focused state, it got unwieldy so we didn't do it. We never got
> around to doing multi-dimensional states, but now it is time to try since
> we can break backward compatibility if we have to. *[0]
>
> I have a couple of suggestions. The first is to create a new State class
> that you could add to your declarations and add more states into it. It
> would look something like this:
>
> 
>
> 
> 
>
>
>
>
> 
>
>
> 
> 
>
>
> 
> 
>   value="true"/>
> 
> 
> 
> 
>   value="false"/>
> 
> 
> 
> 
> 
>
>
> 
>
> 
>
>
> You would use it like this, loginStateGroup.currentState = "loggedIn".
>
> I think this would be the easiest way to add more support. It would use the
> same syntax we already know. It would also be backwards compatible. The
> disadvantages of this would be the lack of support of using states inline.
> So the compiler wouldn't recognize things like this,
>
> .
>
> This second example might be more closely related to the original idea,
>
> 
> 
> 
> 
> 
> 
>
> And you would assign it like this,
>
> currentState = "state3_RedState";
>
> or,
>
> currentState = ["state3", "redState"]; // if renamed to redState
>
> The nested state would inherit the properties of the parent state. The
> thing is there is an inherit property already on the State class. In Flex 3
> we had support for a base state and inheritance. So maybe there's some
> support for this already. I'd really like to know what the Flex team was
> talking about when they mentioned this.
>
> Jude
>
>
>
>
> [0] -
> https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype
>