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://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'.
