[jira] [Resolved] (SCXML-220) History Stack and History States

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SCXML-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved SCXML-220.
-----------------------------
    Resolution: Incomplete

Hi Johannes,

First of all, and like what I said on SCXML-118, please bring questions and ideas like these to the mailing list, don't use JIRA for this.
If such a discussion leads to a more concrete and realistic plan, then of course it can and should be entered into JIRA.

Concerning your idea: I think this is still too vague and needs much more  fleshing out in detail how this ever could work in practice.

A kind of history stack like you describe is definitely a non-trivial and complex feature which I cannot oversee how to implement *and* maintain compatibility with algorithm for SCXML processing.

At any rate: such a feature, if ever practically feasible, is far beyond the current scope of Commons SCXML, where we first still need to reach base compliance with the specification to begin with.

So my suggestion is that you experiment with this yourself and once you get something reasonably working to bring it up again (on the mailing list). Then we can discuss if it might be something worthwhile and fitting for Commons SCXML.
 
Also keep in mind: a <history> pseudo state in SCXML records a current state its history when *exiting* the state, not as you describe when *entering* the state.

> History Stack and History States
> --------------------------------
>
>                 Key: SCXML-220
>                 URL: https://issues.apache.org/jira/browse/SCXML-220
>             Project: Commons SCXML
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Johannes Neuber
>
> Is there a build-in mechanism available to specify *History Stacks* and *History States*?
> Let me explain this:
> Imaging some states of a SCXML specification are associated with certain views/screens (means: they have a visual representation). Other states doesn't... they just contain some logic (means: they are only "transit" states between the visual states). Now the user navigates through the GUI and the different screens/views... So far so good. But now I want to specify a forward/backward navigation like in web browsers. But of course I don't want to associate every view (state) with every (other) view (state) using a back/forward transition (because there could be 1000s of them and thus even more combinations)...
> The easiest way to specify this, would be to have a general automatic build-in mechanism, like the following:
>  
> It should be possible to mark certain states as *"history states"* others not (because not every state should be part of a history!). You could achieve this easily i.e. by setting a <state> attribute (<state id="someState" history="someHistory"/>. This means if the state with id "someState" is entered the state itself (and it's context) will be pushed automatically onto the stack of the <history type="stack" id="someHistory"> element with id "someHistory".
> Then I would only need *one transition* for the event "back" (in my state specification) pointing to my <history id="someHistory">. As soon as you enter this history the last state will be popped from the stack and will be activated ...
> If you couldn't implement this, it would be very helpful to get a hint, how I can integrate this on my own in your code. The only two things I need for a realization are:
> 1. a method to save a certain state (including it's context)
> 2. a method to (re-)activate a previously saved state (including it's context) 
> Thanks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)