[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. 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
Re: [flexcoders] Re: Gosh what a state to be in..
- Original Message - From: florian.salihovic [EMAIL PROTECTED] To: flexcoders@yahoogroups.com 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 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 -- 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
Re: [flexcoders] Re: Gosh what a state to be in..
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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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 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 -- 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
Re: [flexcoders] Re: Gosh what a state to be in..
So are you talking about a state machine table implementation with push - pop based on the tables setup? IE you can only push if the context is this and you can only pop if the context is that This would definitely allow sub-sub states very easily and allow restriction in these sub states. I use this algorithm in an as3 parser. Mike On Tue, Oct 28, 2008 at 8:44 AM, Paul Andrews [EMAIL PROTECTED] wrote: 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] paul%40ipauland.com To: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com 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]florian.salihovic%40gmail.com To: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com 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 flexcoders@yahoogroups.com flexcoders%40yahoogroups.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 -- 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 -- Teoti Graphix, LLC http://www.teotigraphix.com Teoti Graphix Blog http://www.blog.teotigraphix.com You can find more by solving the problem then by 'asking the question'.
Re: [flexcoders] Re: Gosh what a state to be in..
In my particular case it's a drill-down kind of interface, but it's possible to jump to a summary at any stage. Summary is independent of the context. Effectively I'm looking at a 'back' operation. Now that I've said that, I'm wondering - history manager.. - Original Message - From: Michael Schmalle To: flexcoders@yahoogroups.com Sent: Tuesday, October 28, 2008 1:01 PM Subject: Re: [flexcoders] Re: Gosh what a state to be in.. So are you talking about a state machine table implementation with push - pop based on the tables setup? IE you can only push if the context is this and you can only pop if the context is that This would definitely allow sub-sub states very easily and allow restriction in these sub states. I use this algorithm in an as3 parser. Mike On Tue, Oct 28, 2008 at 8:44 AM, Paul Andrews [EMAIL PROTECTED] wrote: 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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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 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 -- 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
