----- Original Message ----- From: "florian.salihovic" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, October 28, 2008 11:59 AM Subject: [flexcoders] Re: Gosh what a state to be in..
> 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. Yes, you're right. > If u have buttons - just register listeners for the interaction and let a > controller decide > what to to depending on the view state. Yes, absolutely. > 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... You are mostly there, but it's not to do with the view components themselves - it's about preserving context between state changes - I'm not suggesting that's a function of the view, it's a controller issue. > Or i just didn't get your intention right... Mostly right. Thanks for posting. Paul > Best regards > > --- In [email protected], "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 >> > > > > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Alternative FAQ location: > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > >
