in reply to Re^2: CGI, DBI, HTTP, SQL - How does it all fit together?
in thread CGI, DBI, HTTP, SQL - How does it all fit together?

Often there will be an index.html initially that presents a form (or a log-in page), which submits its data via POST or GET for CGI.pm to read through the param() method. But it doesn't have to be that way. The client could be led to invoke the CGI program right off the bat (without there being an index.html leading into it.) Your script should detect whether this is an initial call or a later stage in the session. If there's no form data than it can be assumed you've got an initial request, and output your front page. Also, if there is no cookie, you could assume the same. If there is a cookie, it should correspond with a session that you're keeping track of server-side. That session data should keep track of where you are in the site (and program)navigation. Some of this framework is handled by CGI::Session, and CGI::Cookie.

Another topic to consider is trying to separate your HTML from your code. This is where templating systems come in handy (and that's why I referred earlier to HTML::Template). You will also need to deal with access permission and authentication. CGI::Session helps with this. You can also read up on .htaccess.

CGI programming is a topic that can go as deep as you can dig. And that's without even getting into webserver handlers/API, mod_perl, etc. Fun (and potentially frustrating) stuff. ;)


Dave

  • Comment on Re^3: CGI, DBI, HTTP, SQL - How does it all fit together?