Re: [Tclhttpd-users] Re: Checking Page flow redirects etc..????

[Colin M. <co...@ch...>]

On Fri, 2004-10-08 at 01:16, Michael Schlenker wrote:
> Colin McCormack schrieb:
> > On Fri, 2004-10-08 at 00:09, Nicolas Boretos wrote:
> >
> >>Is there any simple or built-in way in tclhttpd for checking your page 
> >>flow, meaning verify that you got to a page from another???
> >  
> > Not that I know of, but it would be a cool project.
> > 
> > What you want (I think) is to drive each user's interaction from a state
> > machine.  Their session starts in state 0, then depending on the inputs
> > they submit, it moves to a different state.
> > 
> > You define a FSM (aka DFSA) which determines which transitions are
> > legal.
> > 
> > There's a tcllib FSM package.  Could be useful for this kind of thing.
> 
> Something like joining the FSM package with the session interpreters and 
> adding some helpers to drive it?

Yes.  I just looked at http://tcllib.sourceforge.net/doc/fa.html and
http://tcllib.sourceforge.net/doc/dexec.html as a result of Nick's
query, and it seems that it would be suitable.

Something like this:

You define a set of states (page names) and a set of transitions and
symbols from state to state.  One of the input variables from a form is
named 'symbol' and the directory .tml checks that symbol represents a
valid transition (by calling [$fa put $symbol] on an fa generated by
[::grammar::fa::dexec] over your DFA.)  One could also calculate
something from form inputs and synthesise a symbol to put into $fa.

If the transition isn't legal, $fa will call an error routine, so you
can generate a redirect and reset the state to some known state.

If the transition is terminal, you close the session, or the
transaction.

The only problem I can see with this model is knowing what state $fa is
currently in, in case that matters ... one could always use a cookie or
a session variable to track the state ... by for example recording the
current page requested (assuming you'd named states for pages, which I
think is a good idea.)

If you felt energetic, you could even write a Tk GUI to specify the DFA.

Anyway, (a) it would ensure that you couldn't end up in a state by
following an illegal path, or in an uncontrolled manner; (b) programming
by DFAs seems seductive, but it can very quickly become unwieldy; (c)
often you need a single transition to some known state (for example, on
input error you might want to restart the transaction) ... if you have a
lot of these, you can nest DFAs - going into a state which means another
DFA is handling input.

I implemented ISO protocols (like X25) in the 80s with this stuff.
-- 
Colin McCormack <co...@ch...>