Re: Multidimensional States
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:
s:states
s:State name=portraitOff stateGroups=off, portrait/
s:State name=portraitOn stateGroups=on, portrait/
s:State name=landscapeOff stateGroups=off, landscape/
s:State name=landscapeOn stateGroups=on, landscape/
s:State name=reportPortrait /
s:State name=reportLandscape /
/s:states
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 (heightwidth) {
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 maxime.co...@gmail.com 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 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
Re: Multidimensional States
On 6/10/13 6:53 PM, flexcapaci...@gmail.com 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:
s:states
s:State name=portraitOff stateGroups=off, portrait/
s:State name=portraitOn stateGroups=on, portrait/
s:State name=landscapeOff stateGroups=off, landscape/
s:State name=landscapeOn stateGroups=on, landscape/
s:State name=reportPortrait /
s:State name=reportLandscape /
/s:states
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 (heightwidth) {
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
TextInput width#isPortrait=100 width=200 /
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
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 fromStatenonDefault toStatedefault
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:strokes: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
Re: Multidimensional States
@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.comwrote:
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 fromStatenonDefault toStatedefault
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:strokes: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
Re: Multidimensional States
On 6/5/13 9:00 PM, flexcapaci...@gmail.com 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,
s:Rect id=focusBorder includeIn={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
On Thu, Jun 6, 2013 at 1:33 AM, Alex Harui aha...@adobe.com 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, State name=blue/ State name=red/ State name=emphasized/ State name=focused/ Label color.blue=blue color.red=red color.emphasized=green/ 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
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 fromStatenonDefault toStatedefault
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:strokes:SolidColorStroke color=...//s:stroke
/s:Rect
/s:Group
On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia cosma...@gmail.comwrote:
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 fromStatenonDefault toStatedefault
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).
Re: Multidimensional States
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 fromStatenonDefault toStatedefault
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:strokes: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 fromStatenonDefault toStatedefault
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).
Re: Multidimensional States
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 fromStatenonDefault toStatedefault
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:strokes: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 fromStatenonDefault toStatedefault
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).
Re: Multidimensional States
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 fromStatenonDefault toStatedefault
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:strokes: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 fromStatenonDefault toStatedefault
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
Re: Multidimensional States
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 fromStatenonDefault toStatedefault
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:strokes: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 fromStatenonDefault toStatedefault
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
Re: Multidimensional States
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: s:states s:State name=state1/ s:State name=state2/ s:State name=state3 basedOn=state2 / /s:states s:HGroup top=30 s:Button label=state 1 click=currentState='state1' / s:Button label=state 2 click=currentState='state2'/ s:Button label=state 3 based on state 2 click=currentState='state3'/ /s:HGroup s:BorderContainer width=300 height=300 verticalCenter=0 horizontalCenter=0 s:Button id=myButton label.state1=Width is 100 label.state2=Width is 200 label.state3=Based on state 2 and color is red width.state1=100 width.state2=200 color.state3=red / /s:BorderContainer 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, s:states s:State name=up/ s:State name=over/ s:State name=down/ s:State name=upDefault basedOn=up/ s:State name=overDefault basedOn=over/ s:State name=downDefault basedOn=down/ s:State name=upFocused basedOn=up/ s:State name=overFocused basedOn=over/ s:State name=downFocused basedOn=down/ s:State name=upDefaultFocused basedOn=up/ s:State name=overDefaultFocused basedOn=over/ s:State name=downDefaultFocused basedOn=down/ /s:states s:HGroup top=30 s:Button label=up click=currentState='up' / s:Button label=over click=currentState='down'/ s:Button label=down click=currentState='over'/ s:Button label=up default click=currentState='upDefault' / s:Button label=over default click=currentState='overDefault'/ s:Button label=down default click=currentState='downDefault'/ s:Button label=up focused click=currentState='upFocused' / s:Button label=over focused click=currentState='overFocused'/ s:Button label=down focused click=currentState='downFocused'/ s:Button label=up focused click=currentState='upDefaultFocused' / s:Button label=over focused click=currentState='overDefaultFocused'/ s:Button label=down focused click=currentState='downDefaultFocused'/ /s:HGroup s:BorderContainer width=400 height=300 verticalCenter=0 horizontalCenter=0 s:layout s:HorizontalLayout / /s:layout s:Button id=myButton label.up=Up label.down=Down label.over=Over / !-- DEFAULT -- s:Label includeIn=upDefault,overDefault,downDefault,upDefaultFocused,overDefaultFocused,downDefaultFocused color=red fontWeight=bold text.up=Default (up) text.over=Default (over) text.down=Default (down) text.upDefaultFocused=Default and Focused (up) text.overDefaultFocused=Default and Focused (over) text.downDefaultFocused=Default and Focused (down) / !-- FOCUSED -- s:Label includeIn=upFocused,overFocused,downFocused,upDefaultFocused,downDefaultFocused,overDefaultFocused color=blue fontWeight=bold text.up=Focused (up) text.over=Focused (over) text.down=Focused (down) text.upDefaultFocused=Default and Focused (up) text.overDefaultFocused=Default and Focused (over) text.downDefaultFocused=Default and Focused (down) / /s:BorderContainer 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: !--s:states s:State name=up/ s:State name=over/ s:State name=down/ s:State name=upDefault basedOn=up stateGroups=default/ s:State name=overDefault
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 aha...@adobe.com 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 bi...@firstpac.com 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:
s:states
s:ExclusiveStateGroup id=mouse
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGroup
s:ExclusiveStateGroup id=focus
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
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.htmlproperty?
On Sat, Jun 1, 2013 at 12:28 PM, jude 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.
snip
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
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 aha...@adobe.com 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 bi...@firstpac.com 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:
s:states
s:ExclusiveStateGroup id=mouse
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGroup
s:ExclusiveStateGroup id=focus
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
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.htmlproperty?
On Sat, Jun 1, 2013 at 12:28 PM, jude 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.
snip
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
Hi, Side thought... will we have an Apache Flex namespace? We already do look at the apache and experimental projects. Justin
Re: Multidimensional States
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:
s:states
s:ExclusiveStateGruop
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGruop
s:ExclusiveStateGruop
s:State name=nonFocused/
s:State name=focused/
/s:ExclusiveStateGruop
s:ExclusiveStateGruop
s:State name=nonDefault/
s:State name=default/
/s:ExclusiveStateGruop
/s:states
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:
s:Rect includeIn=focused alpha=0.5 alpha.default=0.7
...
s:Rect includeIn=focused-nonDefault
Or, we could also supports additional MXML like:
s:Rect alpha.up=0 alpha.over=0.5 alpha.over-focused=1.0 ...
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 aha...@adobe.com
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:
s:states
s:State name=up/
s:State name=down/
s:State name=over/
/s:states
And some widgets in the skin look like:
s:Rect id=focusBorder includeIn(isFocused)=
left(emphasized)=-2 left=-1 /
s:Rect id=background color.up=... color.down=...
color(currentState==upemphasized)
Now, when I look at that, I wonder: why not just use binding?
s:Rect id=focusBorder includeIn={isFocused}
left={emphasized ? -1 : -2} /
s:Rect id=background color.up=... color.down=...
color={(currentState==upemphasized) ? 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:
s:Rect id=focusBorder className=buttonFocusBorder
s:Rect id=background className=buttonBackground
And CSS like:
.buttonFocusBorder#focusBorder[emphasized] {
left: -2;
}
.buttonFocusBorder#focusBorder {
left: -1;
}
.buttonBackground#background[emphasize] {
RE: Multidimensional States
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:
s:states
s:ExclusiveStateGroup id=mouse
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGroup
s:ExclusiveStateGroup id=focus
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
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
stateGroupshttp://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf63611-7ffa.htmlproperty?
On Sat, Jun 1, 2013 at 12:28 PM, jude 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.
snip
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
Hi Cosma,
Thanks for presenting this possible approach.
-Alex
On 6/3/13 12:45 AM, Cosma Colanicchia cosma...@gmail.com 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:
s:states
s:ExclusiveStateGruop
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGruop
s:ExclusiveStateGruop
s:State name=nonFocused/
s:State name=focused/
/s:ExclusiveStateGruop
s:ExclusiveStateGruop
s:State name=nonDefault/
s:State name=default/
/s:ExclusiveStateGruop
/s:states
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:
s:Rect includeIn=focused alpha=0.5 alpha.default=0.7
...
s:Rect includeIn=focused-nonDefault
Or, we could also supports additional MXML like:
s:Rect alpha.up=0 alpha.over=0.5 alpha.over-focused=1.0 ...
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 aha...@adobe.com
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:
s:states
s:State name=up/
s:State name=down/
s:State name=over/
/s:states
And some widgets in the skin look like:
s:Rect id=focusBorder includeIn(isFocused)=
left(emphasized)=-2 left=-1 /
s:Rect id=background color.up=... color.down=...
color(currentState==upemphasized)
Now, when I look at that, I wonder: why not just use binding?
s:Rect id=focusBorder includeIn={isFocused}
left={emphasized ? -1 : -2} /
s:Rect id=background color.up=... color.down=...
color={(currentState==upemphasized) ? 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:
s:Rect id=focusBorder className=buttonFocusBorder
s:Rect id=background className=buttonBackground
And CSS like:
Re: Multidimensional States
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 bi...@firstpac.com 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:
s:states
s:ExclusiveStateGroup id=mouse
s:State name=up/
s:State name=down/
s:State name=over/
/s:ExclusiveStateGroup
s:ExclusiveStateGroup id=focus
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
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
stateGroupshttp://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e
3d11c0bf63611-7ffa.htmlproperty?
On Sat, Jun 1, 2013 at 12:28 PM, jude 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.
snip
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
On 6/1/13 3:28 AM, flexcapaci...@gmail.com 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
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 aha...@adobe.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. 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
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'. s:states s:State name=up stateGroups=upStates,normal/ s:State name=down stateGroups=downStates,normal/ s:State name=over stateGroups=overStates,normal/ s:State name=upAndDefault stateGroups=upStates,default/ s:State name=downAndDefault stateGroups=downStates,default/ s:State name=overAndDefault stateGroups=overStates,default/ s:State name=upAndFocused stateGroups=upStates,focused/ s:State name=downAndFocused stateGroups=downStates,focused/ s:State name=overAndFocused stateGroups=overStates,focused/ s:State name=upAndDefaultAndFocused stateGroups=upStates,default,focused/ s:State name=downAndDefaultAndFocused stateGroups=downStates,default,focused/ s:State name=overAndDefaultAndFocused stateGroups=overStates,default,focused/ /s:states The states declaration looks heavy and is rather hard to decipher: -1 The actual component would look something like: s:Rect id=focusBorder includeIn=focused/ s:Rect id=background color.upStates=... color.downStates=... 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: s:Rect id=background color.upStates=... color.downStates=... 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': s:states s:State name=up/ s:State name=down/ s:State name=over/ s:State name=focused/ s:State name=default/ /s:states Well that's extremely terse and clear: +2 The actual component would look something like: s:Rect id=focusBorder includeIn=focused/ s:Rect id=background color.up=... color.down=... 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: s:Rect id=background color.up=... color.down=... 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 arn...@artim-interactive.nlwrote: 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 aha...@adobe.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. 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
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:
s:states
s:State name=up/
s:State name=down/
s:State name=over/
/s:states
And some widgets in the skin look like:
s:Rect id=focusBorder includeIn(isFocused)=
left(emphasized)=-2 left=-1 /
s:Rect id=background color.up=... color.down=...
color(currentState==upemphasized)
Now, when I look at that, I wonder: why not just use binding?
s:Rect id=focusBorder includeIn={isFocused}
left={emphasized ? -1 : -2} /
s:Rect id=background color.up=... color.down=...
color={(currentState==upemphasized) ? 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:
s:Rect id=focusBorder className=buttonFocusBorder
s:Rect id=background className=buttonBackground
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 maxime.co...@gmail.com 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'.
s:states
s:State name=up stateGroups=upStates,normal/
s:State name=down stateGroups=downStates,normal/
s:State name=over stateGroups=overStates,normal/
s:State name=upAndDefault stateGroups=upStates,default/
s:State name=downAndDefault stateGroups=downStates,default/
s:State name=overAndDefault stateGroups=overStates,default/
s:State name=upAndFocused stateGroups=upStates,focused/
s:State name=downAndFocused stateGroups=downStates,focused/
s:State name=overAndFocused stateGroups=overStates,focused/
s:State name=upAndDefaultAndFocused
stateGroups=upStates,default,focused/
s:State name=downAndDefaultAndFocused
stateGroups=downStates,default,focused/
s:State name=overAndDefaultAndFocused
stateGroups=overStates,default,focused/
/s:states
The states declaration looks heavy and is rather hard to decipher: -1
The actual component would look something like:
s:Rect id=focusBorder includeIn=focused/
s:Rect id=background color.upStates=... color.downStates=...
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:
s:Rect id=background color.upStates=... color.downStates=...
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
Re: Multidimensional States
How is that different from the already existing
stateGroupshttp://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf63611-7ffa.htmlproperty?
On Sat, Jun 1, 2013 at 12:28 PM, jude 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.
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:
Group
!-- default build in states we use now --
states
State name=page1/
State name=page2/
State name=page3/
State name=settings/
/states
!-- new additional helper state group --
declarations
StateGroup id=loginStateGroup
State name=loggedIn
overrides
SetProperty target='{button} property=color
value=red/
SetProperty target='{this} property=isAuthenticated
value=true/
/overrides
/State
State name=loggedOut
overrides
SetProperty target='{button} property=color
value=blue/
SetProperty target='{this} property=isAuthenticated
value=false/
/overrides
/State
transitions
Transitions... /
/transitions
/StateGroup
/declarations
/Group
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,
Button color.loggedIn=red /.
This second example might be more closely related to the original idea,
State name=state1/
State name=state2/
State name=state3
State name=state3_RedState/
State name=state3_BlueState/
/State
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
Re: Multidimensional States
Usually I solve this by just overriding the getCurrentState method and a
having all the posible options in the states group.
J
On Sat, Jun 1, 2013 at 6:41 AM, John Cunliffe mahn...@gmail.com 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 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.
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:
Group
!-- default build in states we use now --
states
State name=page1/
State name=page2/
State name=page3/
State name=settings/
/states
!-- new additional helper state group --
declarations
StateGroup id=loginStateGroup
State name=loggedIn
overrides
SetProperty target='{button} property=color
value=red/
SetProperty target='{this} property=isAuthenticated
value=true/
/overrides
/State
State name=loggedOut
overrides
SetProperty target='{button} property=color
value=blue/
SetProperty target='{this} property=isAuthenticated
value=false/
/overrides
/State
transitions
Transitions... /
/transitions
/StateGroup
/declarations
/Group
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,
Button color.loggedIn=red /.
This second example might be more closely related to the original idea,
State name=state1/
State name=state2/
State name=state3
State name=state3_RedState/
State name=state3_BlueState/
/State
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
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 jonbcam...@gmail.comwrote:
Usually I solve this by just overriding the getCurrentState method and a
having all the posible options in the states group.
J
On Sat, Jun 1, 2013 at 6:41 AM, John Cunliffe mahn...@gmail.com 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 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.
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:
Group
!-- default build in states we use now --
states
State name=page1/
State name=page2/
State name=page3/
State name=settings/
/states
!-- new additional helper state group --
declarations
StateGroup id=loginStateGroup
State name=loggedIn
overrides
SetProperty target='{button} property=color
value=red/
SetProperty target='{this}
property=isAuthenticated
value=true/
/overrides
/State
State name=loggedOut
overrides
SetProperty target='{button} property=color
value=blue/
SetProperty target='{this}
property=isAuthenticated
value=false/
/overrides
/State
transitions
Transitions... /
/transitions
/StateGroup
/declarations
/Group
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,
Button color.loggedIn=red /.
This second example might be more closely related to the original idea,
State name=state1/
State name=state2/
State name=state3
State name=state3_RedState/
State name=state3_BlueState/
/State
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
