Question
Enhanced States Syntax
I just saw that Flex 4 state names will be restricted to the intersection valid AS3 and XML identifiers. What is the rationale behind that?
This conflicts with how we are using URI's for hierarchical states within our application framework. We can pretty easily get around it by using a subclass of state, that adds a uri property instead of using name, and we were already considering doing that anyway for other reasons. But, in case it is helpful or anyone wants to discuss this, I'll explain what we are doing:
Our apps use a global state string, which is a URI. Individual views define states which may match parts of that URI, and respond to global state change by assuming the closest parent-or-self to the global state.
For example, a view might define states:
"/a"
"/a/b/c"
"/a/b/d"
"/a/b"
If the global state is "/a/b/c" then the view will go into state "/a/b/c",
If the global state is "/a/b/foo/bar" then the view will go into the
state "/a/b",
If the global state is "/a/xyz/abc" then the view will go to the state "/a".
This structure lets us control states very cleanly, without knowledge
of the actual views, and it separates the containment structure of the views from the screens that have been designed and approved by a client. The result is that the views know how to render themselves in any given application state, but you don't need to know how to address any particular view component instance in order to make it do that.
Peter
This conflicts with how we are using URI's for hierarchical states within our application framework. We can pretty easily get around it by using a subclass of state, that adds a uri property instead of using name, and we were already considering doing that anyway for other reasons. But, in case it is helpful or anyone wants to discuss this, I'll explain what we are doing:
Our apps use a global state string, which is a URI. Individual views define states which may match parts of that URI, and respond to global state change by assuming the closest parent-or-self to the global state.
For example, a view might define states:
"/a"
"/a/b/c"
"/a/b/d"
"/a/b"
If the global state is "/a/b/c" then the view will go into state "/a/b/c",
If the global state is "/a/b/foo/bar" then the view will go into the
state "/a/b",
If the global state is "/a/xyz/abc" then the view will go to the state "/a".
This structure lets us control states very cleanly, without knowledge
of the actual views, and it separates the containment structure of the views from the screens that have been designed and approved by a client. The result is that the views know how to render themselves in any given application state, but you don't need to know how to address any particular view component instance in order to make it do that.
Peter
AdChoices