Hi Jeffry, Hopefully this gets added to the list in the right way as I'm cutting and pasting from reading the search archives.
Incidentally, we should include instructions on how to search the archives on the home page for the project, it's very difficult to locate instructions, in the end I had to just guess and go by trial and error, the exact same folk who will ask questions that have already been answered are the ones that won't go to the trouble of guessing how to do it. Anyway I can think of a number of cases where dynamic states would be useful. Largely to cover cases where during the lifetime of an application the amount and type of data will grow to very different dimentions. Say it's a traditional photo viewer app. The basic use case is that someone is viewing one set of photos that they've uploaded and you show them thumbnails. once they've loaded 20 or 20 photos, maybe you add a scrollbar and change the layout some, A year later they have hundreds of photos and you want a totally different view. five years down the road they have 5000 photos to browse. Yes you could define all of these cases up front with different declarative layouts, but what if in addition to photos the user can store a dozen different other kinds of things, and some of those things they want to be able to tag and group in unpredictable ways? In this case where no one user is likely to choose the same set of things to do, you can either add an exponential number of layouts to your declarative interface, all of which are being typed in and compiled even though a slight number are being used by any one user, or you can code it with some rules of thumb and dynamic states. In response to Carlos's original post I'd put 4 things on my wish list for flex 5 to be successful. 1) The remaining important spark components (thanks to adobe for committing to this) 2) a simple "kitchen sink" app that uses all the components and transitions to test skins with 3) two or three good looking professional spark skins 4) A skinning tool for spark components similar to the old Flex style explorer. After that my three nice to haves would be 5) multidimentional / hierarchical states 6) Dynamic states, 7) A manager for saving view states in lso's I would worry about replacing the spark architecture with zippy mobile ones after that. Mobile is important and is getting all the buzz, but there are many applications that will always work better with a mouse, a keyboard and a large screen. That's what the Flex framework was designed for and that is it's natural niche, though I have total faith that a simplified version can be made to fit the mobile market as well. Anyway thanks for asking. Do you have a use case for dynamic view states? I can honestly say I've never been limited by the current implementation. In the Flex 3 era you could define states on the fly; but it could be a pain. I have never dug into the underpinnings of the Spark State system, though. On 1/9/2012 11:37 AM, Nick Collins wrote: * Dinamic View States we have fully support of "dinamic *skin* parts" in Flex 4 and work great, but one thing we need too is "dinamic view states". Right now view states need to be declared in the AS3 class and in the *skin*. So this is all very "declarative". We need the capability to create states on the fly and let other parts handle this dinamic view states (transitions,...). Without this, view states are a bit limited. -- Jeffry Houser Technical Entrepreneur 203-379-0773 -- http://www.flextras.com?c=104 UI Flex Components: Tested! Supported! Ready! -- http://www.theflexshow.com http://www.jeffryhouser.com http://www.asktheflexpert.com -- Part of the DotComIt Brain Trust
