In my case, on refection, it's probably easier to build separate state variants, so I'll have state A, B, C and the default, plus states aC and bC (going from a to C and from b to C). By using states aC and bC I can hide the view components that would otherwise be removed by just having a state C. By just hiding the components I can preserve their context. This strategy just wont work if there are too many states involved.
Paul ----- Original Message ----- From: "Paul Andrews" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, October 28, 2008 12:05 PM Subject: Re: [flexcoders] Re: Gosh what a state to be in.. > ----- 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 >> >> >> > > > ------------------------------------ > > -- > 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 > > >
