Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: CGI: Nodes vs State Machine

by edebill (Scribe)
on Jan 15, 2002 at 22:45 UTC ( [id://138992] : note . print w/replies, xml ) Need Help??


in reply to CGI: Nodes vs State Machine

First off: Cool. I've not seen anyone really talk about this, and I think it's important.

That said, you can always look at the series of "pages" users will view as a state machine. The only difference between your two implementations is how you define the state transition rules.

Even a traditional flat HTML website - current state is stored in the user's browser (what URL they are on) and transition rules are in the form of href's.

Disclaimer: I've not looked at CGI::Application. I've looked at Everything, but not used it.

Obviously, different approaches will work best on different sites. My worry about Everything is that for a high traffic website, the db will be the bottleneck. databases don't scale nearly as well as webservers (especially when you can just add more webservers to the farm). For a low/medium traffic site it probably doesn't matter at all.

Out of curiosity, why rule out the traditional "collection of CGI's" method? It keeps transition information local to the individual files (you might have 1 CGI that did the entry/validation/success, 1 for change password, 1 for edit/preview/submit, etc), doesn't store it in the db (so the db can do more important things - like storing content), and has a fairly short learning curve. Is your site intended to just be too dynamic (changing structure all the time)?

Replies are listed 'Best First'.
Re: Re: CGI: Nodes vs State Machine
by Masem (Monsignor) on Jan 15, 2002 at 23:14 UTC
    Right now the site IS a collection of CGI scripts that do individual states. Sure, it works, but even using a common routine module, a change in one part of the script might need updating elsewhere. I'd rather have a system where there is one common starting point for authenication checking, cookie collection, and the like, and similar exit point for rendering and logging, as to avoid code duplication. Providing such hooks such that the CGI functions are considered plugins, as opposed to common routines being plug-ins for the CGI, can make the code more uniform, and easier to update. Using CGI::Application with a huge state machine or a node system would handle both of these isssues.

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
    "I can see my house from here!"
    It's not what you know, but knowing how to find it if you don't know that's important