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.com>wrote: > 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 >
