Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

CGI: Nodes vs State Machine

by Masem (Monsignor)
on Jan 15, 2002 at 20:44 UTC ( [id://138943]=perlmeditation: print w/replies, xml ) Need Help??

In this previous node on my attempts to rewrite a CGI system that I have, many gave good advice, and one of the things that I'm looking into is the use of CGI::Application for backends. However, there's a couple of problems that I see with this:
  • First, it seems, as I read examples, that you would want to use a new instance of CGI::Application for each state machine that you have (such as a "Entry/Validataion/Success" series), and if you have a second state machine, you'd want to use a new CGI::Application for it. Not that you couldn't use one C:A for it, but it can become overwhelming to maintain it. Since the site I'm updating has many different state machines, this would seem to preclude the use of CGI::Application. Using Nodes, on the other hand, would require additional db calls, but if you follow the example that PM has, there's several instances of state machines at work (such as preview/submit/display for most nodes), which can be easily done by linking nodes. I am going to use Postgres for this, so I have the ability to inherit node types in the db, so that makes things a bit nicer. Now, in my case, node creation is not a task that would be done often; most likely it would be limited to some feedback areas and when I specifically add new text to the site. So in this case, would using nodes be too much for this type of site?
  • In addition, I have some pages that do not require a user account to view, some where the user account isn't necessary but can help set default views, and some where it's required. Typically, if I used individual state machine C:A model above, each state machine would have the same authentication scheme as above. However, if I used a global state machine, there appears to be no easy way to specify extra steps to take once C:A takes over. With nodes, I can specify which node types need which authenication, and use that as well. So doing this by the node route isn't a problem, but I stuck with C:A, is there an add-on or similar package that allows authenication specification or similar pre-engine features?
Yes, as I read back this, it seems like I'm set on the node model, but I'm still looking for gotcha's that might come into play. But does it make more sense to go the way of the node instead of large state machines for CGI apps in the general case?

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

Replies are listed 'Best First'.
Re: CGI: Nodes vs State Machine
by edebill (Scribe) on Jan 15, 2002 at 22:45 UTC

    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)?

      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

Re: CGI: Nodes vs State Machine
by perrin (Chancellor) on Jan 16, 2002 at 02:22 UTC
    First, I don't know what you mean by a "Nodes" model. Are you talking about vanilla CGI? If so, what's all this about requiring a database and inheritance in Postgres?

    It looks to me like you are confusing the sort of state machine support that CGI::Application gives with application-wide authentication and user tracking. That stuff is typically done through the use of some session tracking mechanism (like Apache::Session or similar), and you will need all requests to be processed by a particular piece of code to make it happen.

    mod_perl provides hooks to add your own modules in at the auth and access stages of Apache, but you can do this anywhere. If you use CGI::Application, you can do it in the cgiapp_init() method. Just write some shared module that loads the current session and checks the user's authorization to view this page, and call this module from cgiapp_init(). You could do the same from vanilla CGI.

    You could also use a framework like OpenInteract which already has the user tracking and auth stuff built in.

      By a node system, I refer to basically what the Everything engine that powers PM is. That is, there is only one CGI script that is accessed by the end user, and the key param that is passed to that script is the node ID. This node ID is looked up in a database to determine its type as well as additional information for the node. This type determine any further programming logic that should be implemented using subroutines. A state machine in a node setup is basically linking nodes together in a series of steps as appropriate by the logic.

      At least, that's how I'm defining it. I definitely wouldn't call it vanilla CGI.

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

        Okay, that makes more sense. I still think that's not related to user access control. The access control is something that a shared piece of code would do, be it invoked by your single uber-CGI, or by a bunch of separate CGI::Application scripts, or something totally different. It's orthogonal to your choice about how to organize the actions available on your site.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://138943]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (3)
As of 2024-03-29 06:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found