commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <>
Subject [jira] [Resolved] (SCXML-220) History Stack and History States
Date Tue, 28 Oct 2014 00:31:34 GMT


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

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:
>             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

View raw message