in reply to CGI: Nodes vs State Machine

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.

Replies are listed 'Best First'.
Re: Re: CGI: Nodes vs State Machine
by Masem (Monsignor) on Jan 16, 2002 at 03:15 UTC
    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.