Re: [ANNOUNCE] StateMachine::Gestinanna 0.06

[James G Smith <JG...@TAMU.Edu>]

"William McKee" <wi...@knowmad.com> wrote:
>On 25 Oct 2002 at 1:25, James G Smith wrote:
>> This module can be used for some of the same applications as
>> CGI::Application.  It can also be used outside the web environment.
>> It does not handle sessions and other application-dependent
>> data management.
>
>Hi James,
>
>I've been following your posts about Gestinanna because I currently use 
>CGI::Application and really like it. Can you give any reasons why someone 
>would want to use your module instead? I'm all for having choices but like 
>to know the rationale behind the different distributions of similar 
>modules.

No problem.

Almost all (just in case there are some that aren't, especially in
Acme::) modules on CPAN are there because they solve some problem.
Even modules that do essentially the same thing are solving slightly
different problems.  

I think this is the case with CGI::Application and my module.  We
have essentially the same problem, but slightly different
requirements.  I'm concerned more with certain security and OO
aspects than with initial ease of use.  CGI::Application is good at
what it does, from what I can tell, but doesn't address those two
sufficiently for me to be comfortable using it where I am working.
Thus the difference in design.

I'm working on an application framework for an account/system
administration web interface.  I'm having to think reliability and
security.  At the same time, I'm having to consider ease of use for
those developing applications within the framework.  I chose to
follow the MVC paradigm (discussed some time ago on this list) to
accomplish this.

The controller is basically a state machine.  It looks at what comes
in from the client, decides what needs to be done and what view needs
to be sent back.  Thus StateMachine::Gestinanna.  It manages state
based on the data from the client (instead of relying on the client
to tell it the next state) with minimal requirements for how the
application does views or manages persistance (sessions and contexts)
and client interaction.

I'm also trying to develop a system that allows applications to be
distributed on CPAN and installed as any module on CPAN would be
installed.  Uttu is the basis for that system, but the idea spilled
over a little into this module and drove the development of the
object-oriented features.

I can write an abstract state machine that has holes in it, but has
enough there to guide the development of a useful state machine.  For
example, we have a process for activating an account on one of our
systems.  It involves providing sufficient information to convince us
you are who you are, agreeing to the terms of services, selecting
usernames and a password, and confirming that you want what you
selected.  I would not distribute the finished state machine, but one
that described the general flow and provided the edges for
terms-of-service->edit and for confirm->done.  The others depend on
what information is required for a given system.  The code would need
to also be written that needs to run when the state transitions.

An example making fairly good use of inheritance is account
creation.  If there are several account types that are essentially
the same except for some details in types of data required, then a
basic state machine can be written that manages the data required for
all account types.  Then a set of child classes can be developed, one
per account type, with the information/code specific to that account
type.  These can then all be combined in one class using HASA
relationships to make one account addition application.  Adding an
account type is then trivial.

Hopefully that helps a little.  I probably should polish it up some,
expand on a few things, and submit it as an article somewhere :/
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix