Hm, actually i don't quite get the problem, i think. States should be used in my opinion to really abstract view-states. The state of the application should be stored in a domain model.
If u have buttons - just register listeners for the interaction and let a controller decide what to to depending on the view state. As i understand your problem it's like you have different states, which not only refer to view states but als to states in terms of functionality which is bound directly to a statewhich i think leads to too much logic in view components... Or i just didn't get your intention right... Best regards --- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > I think I know the answer to this, but here goes.. > > Lets suppose I have an application with states A, B and C, plus the default. > > There are buttons in states A, B and default to switch the application to > state C. > > That would be all fine and dandy, but once I have entered state C, I can > press a button to leave state C and return to the state from whence it was > called (A, B or default). > > Still, no problem with that, but I'd like to keep the context of the > previous state so that when I return to state A (for example) from state C, > I can present the same view as before. > > Similarly, it may be that state B is really a substate of A (state Ab, if > you like), so returning to the status quo might be a bit more difficullt. > > Really speaking I just need a state/state context stack that I push and pop > as I move from one state to the next and back. > > Anyone already done similar with a different approach? > > I know I could get away without the stack if I implemented variants of state > C that took into account the 'calling' state, but it quickly becomes a > nightmare. > > This is certainly doable, I'm just seeing if there's a tried and tested way > of managing state contexts like this. > > Paul >
