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

Excellent response, thank you.

To answer your question, I have used perl in the past to analyze large quantities of data from txt files. I have also done DB interaction in the past using postgreSQL & PHP, although the database system was already in place. I have never used perl CGI.

I will be picking up a copy of those books if I can find them at a local library.

So, from what I gather, a theoretical script would:

(a) Recieve a signal from a webserver using CGI param() and render the webpage using print() with HTML markup to create things like text fields for user data input.

(b) Use CGI to read in user input from those text fields (once again through param())

(d) Update webpage with CGI, display something like a table with the requested data retrieved using DBI.

Is the way in which the TWiki webpage communicates with my perl script dependent on the host (?terminology? -- referring to TWiki), or is there a resource that can help me understand that process as well?

Thanks once again,

Somewhat less confused.. but still confused

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

Replies are listed 'Best First'.
Re^3: CGI, DBI, HTTP, SQL - How does it all fit together? by davido (Cardinal) on May 04, 2011 at 19:59 UTC
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	[reply]

Replies are listed 'Best First'.

Re^3: CGI, DBI, HTTP, SQL - How does it all fit together?
by davido (Cardinal) on May 04, 2011 at 19:59 UTC

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

[reply]