Perl site - Elementary question

[kejoseph]

Hi,

I want to setup a "quick and dirty" site which grabs information from
users (in a form having 8-10 fields) and dumps it to a database. Later
I will grab this information and display it in a nice format.

I want to use Apache and Perl to achieve the same. I am a bit
overwhelmed with all the information and hence wish to see some
clarification via this newsgroup.

1. What is the difference between mod_perl 2.0 , lwp module and cgi
module ?
2. I have setup Apache 2.0 with mod_perl 2.0. I have also created the
form which contains the information the user will send. How do I gather
or receive the form information (sent via html POST) in perl - should I
use lwp or cgi module or is there something with mod_perl 2.0 ?

Please advise,
Kevin.

 

[usenet]

I want to setup a "quick and dirty" site which grabs information from
users (in a form having 8-10 fields) and dumps it to a database.

If you mean a "real" database like MySQL (as opposed to appending info
to a textfile, sometimes loosely called a "database") then you have a
whole new area of programming to be 'overwhelmed' with.

I want to use Apache and Perl to achieve the same.

Good choice.

What is the difference between mod_perl 2.0 , lwp module and cgi module?

You won't use lwp for your project. You don't need to understand how
mod_perl works - just "use strict" and it should run fine with or
without mod_perl (the only thing mod_perl does for you - at least at
your level - is improve performance. You WILL use the CGI module.

2. I have setup Apache 2.0 with mod_perl 2.0. I have also created the
form which contains the information the user will send.

What you have probably created is a pure HTML form. The usual "Perl"
approach would be to have a script that generates the form "on the fly"
and that same script also processes the form. So you never write HTML.
Instead of:
<a href="www.google.com">Google</a>
you write:
a({href => 'www.google.com}, "Google")
This is all done using the CGI.pm module, which will become your best
friend.

How do I gather or receive the form information ... in perl

That's where you use the CGI.pm module. Since you've (probably) written
your form already in pure HTML, you have the form's "target" call a
Perl CGI script, which processes the parameters and does whatever you
want.

As others have pointed out, there is TONS of info on the web about
this. Also, Lincoln Stein, the author of the CGI.pm module, wrote a
book about it, which you can get on Amazon (http://tinyurl.com/e3lpz)
or many other places. It has step-by-step illustrated examples of
EXACTLY what you are trying to do.

 

[Gunnar Hjalmarsson]

So you never write HTML. Instead of:
<a href="www.google.com">Google</a>
you write:
a({href => 'www.google.com}, "Google")
This is all done using the CGI.pm module,

Cool!

 

[Juha Laiho]

(e-mail address removed) said:

What you have probably created is a pure HTML form. The usual "Perl"
approach would be to have a script that generates the form "on the fly"
and that same script also processes the form. So you never write HTML.
Instead of:
<a href="www.google.com">Google</a>
you write:
a({href => 'www.google.com}, "Google")
This is all done using the CGI.pm module, which will become your best
friend.

There are places where a pure HTML form (not having any generated content)
is a good thing -- if you're going to have a form which is always
exactly the same for all clients, then there's no point in generating
that for each request. It makes much more sense to just write it in
HTML (or perhaps pre-generate it once from some kind of template and
then serve the generated form from a file.

Also, the above example doesn't do much magic -- the benefits of
HTML generation are largely in keeping the tags in balance. So, in
the above, the HTML generation will handle the "</a>" tag to be emitted
in the correct place, without needing to write one. Below is a more
complex example, which I think is better in highlighting the benefits
of generation (from CGI.pm docs):

print ul(
li({-type=>'disc'},['Sneezy','Doc','Sleepy','Happy'])
);

This example will result in HTML output that looks like this:

<ul>
<li type="disc">Sneezy</li>
<li type="disc">Doc</li>
<li type="disc">Sleepy</li>
<li type="disc">Happy</li>
</ul>

.... and in the above the "['Sneezy','Doc','Sleepy','Happy']" can be any
form of array reference (so, the data can be generated elsewhere in the
program, and reference to the array containing the data can be passed
to the routine generating the HTML).

HTML tables can be constructed similarly, as well as various form elements
(selection lists, button groups, ...). These go long way in always having
HTML in correct form, as the close tags (and a lot of other details) are
handled by the CGI module. One benefit of correct HTML is much less
"surprises" in how a page is rendered in different browsers.

 

[usenet]

There are places where a pure HTML form (not having any generated content)
is a good thing.

I don't necessarily dispute that. I didn't chastise the OP for using a
pure HTML form - I simply pointed out that this was not the usual
practice of Perl CGI scripts (as documented in Stein's perldocs and
book). But, IMHO, if you are using CGI.pm for the form processing (this
is NOT a troll for PG), it seems natural to use CGI.pm for the form
presentation as well. Personally, though, I generate all my forms with
a CGI.pm-based script using HTML::Template (I write a program that
generates my templates - but I'm weird).

 

[Gunnar Hjalmarsson]

I didn't chastise the OP for using a pure HTML form - I simply
pointed out that this was not the usual practice of Perl CGI scripts
(as documented in Stein's perldocs and book).

Methods in CGI.pm is not necessarily "the usual practice". I for one
don't know what "the usual practice" is, but I know that I personally
prefer here docs over generating HTML via CGI.pm, and that several
others in this group do so as well.

 

[Gunnar Hjalmarsson]

I personally prefer here docs over generating HTML via CGI.pm,

That should be 'here docs or templates'.

 

[Brian Wakem]

If you mean a "real" database like MySQL (as opposed to appending info
to a textfile, sometimes loosely called a "database") then you have a
whole new area of programming to be 'overwhelmed' with.

Technically a flatfile database *is* a database, as a database is simply
where the info is stored. A 'real' database like MySQL is actually a
database management system, which ultimately stores everything in a file,
which is the 'database'.

 

[Matt Garrish]

Technically a flatfile database *is* a database, as a database is simply
where the info is stored. A 'real' database like MySQL is actually a
database management system, which ultimately stores everything in a file,
which is the 'database'.

And there are people who would argue that MySQL is not a "real" database...
: )

Matt

 

[fishfry]

Technically a flatfile database *is* a database, as a database is simply
where the info is stored. A 'real' database like MySQL is actually a
database management system, which ultimately stores everything in a file,
which is the 'database'.

A "real" database in this context is a *relational* database, which is
different from a flat file database. You could in theory have a "flat
file database management system" although nobody does that.

 

[A. Sinan Unur]

A flat file database is frequently relational. Consider the /etc/passwd
and /etc/group files. Each is a single table with rows (lines) and
columns (fields); and relations exist between the two.

You are misunderstading the meaning of "relational" in the context of
databases. The word "relation" refers to relations between tables, and the
operations allowed on them.

Sinan

 

[Samwyse]

@newssvr11.news.prodigy.com:



You are misunderstading the meaning of "relational" in the context of
databases. The word "relation" refers to relations between tables, and the
operations allowed on them.

You, on the other hand, have never heard of DBD::CSV, which maps
databases onto directories, and tables onto individual files within that
directory.

require DBI;
my $dbh = DBI->connect("DBI:CSV:");
$dbh->{'csv_tables'}->{'passwd'} = {
'eol' => "\n",
'sep_char' => ":",
'quote_char' => undef,
'escape_char' => undef,
'file' => '/etc/passwd',
'col_names' => ["login", "password", "uid", "gid", "realname",
"directory", "shell"]
};
$sth = $dbh->prepare("SELECT * FROM passwd");

 

[A. Sinan Unur]

You, on the other hand, have never heard of DBD::CSV, which maps
databases onto directories, and tables onto individual files within
that directory.

I know exactly what DBD::CSV is, and I do know that it allows one to
query CSV files using SQL syntax. I also know that does not a relational
database make.

You do not seem to know what you do not know.

I any case, relational databases are not really topical here, so I'll
stop now.

Feel free to seek clarification in comp.databases.theory.

Sinan

 

[Smitty]

You, on the other hand, have never heard of DBD::CSV, which maps

databases onto directories, and tables onto individual files within that
directory.

require DBI;
my $dbh = DBI->connect("DBI:CSV:");
$dbh->{'csv_tables'}->{'passwd'} = {
'eol' => "\n",
'sep_char' => ":",
'quote_char' => undef,
'escape_char' => undef,
'file' => '/etc/passwd',
'col_names' => ["login", "password", "uid", "gid", "realname",
"directory", "shell"]
};
$sth = $dbh->prepare("SELECT * FROM passwd");

OK, So, let's see a join !

Generally speaking it is foolish to tell someone they don't know about
something.

 

[Samwyse]

I know exactly what DBD::CSV is, and I do know that it allows one to
query CSV files using SQL syntax. I also know that does not a relational
database make.

You do not seem to know what you do not know.

I any case, relational databases are not really topical here, so I'll
stop now.

Feel free to seek clarification in comp.databases.theory.

I've been a DBA of sorts at various times in my career, and have
understood relational algebras for several decades now. At their base,
all databases are represented by sequential orderings of bits; there is
nothing in Date or Codd's works that indicate to me that flat files
could not be used as such a representation.

You remind me of a job interviewer in the 80's who asked if I knew
client-server architectures. I explained that I knew about RPC, X11,
and other instances of clients and servers, but they were only
interested in someone with experience writing Visual Basic applications.

 

[A. Sinan Unur]

I've been a DBA of sorts at various times in my career, and have
understood relational algebras for several decades now. At their
base, all databases are represented by sequential orderings of bits;
there is nothing in Date or Codd's works that indicate to me that flat
files could not be used as such a representation.

Oh, but your claim was that DBD::CSV turned flat files into a relational
database system.

Now, I am stopping for real. Bye.

Sinan