Re: What Comes Next?

http://www.perl.com/pub

I know a little about lots of stuff that was on the scene a few years back.
I'm getting back up to speed with knewer stuff.

I learnt perl because I like to write things from scratch, I'm attracted to
the spirit of co-operation getting us all further, and it was the thing to
process forms, get files on your server updated with stuff happening on your
site, do database things without hiding suff from me, and get email to
happen as a result of site user action.

I haven't used php, but it seems to me that it resembles what are termed
modules in perl. You know, where a guy creates all this code that focuses on
a specific task and gives you an access to those tasks with names that are
meaningful in the context of the actual work you are trying to do, rather
than the workings of the computer code.

php is very popular, so if I was me 4 years ago today I'd probably stumble
onto php instead of perl.

But if you want to get close to the inner workings, perl takes you there.

I'll recall my get up and going lessons with perl.

1. Know the path to perl on your server. This will be the first line on
every perl script. For me it is:

#/usr/bin/perl  [nb ... it dosn't need a ';' this first line]

and for you it is bound to be the same or very similar - it's a common usage
thing without being a strict standard, I think

2. Understand that fundamentally, or maybe pratically, cgi means data pairs
[name-value], and includes things like REMOTE_ADDR [the bit that lets the
CIA pin down your isp along with a couple of other data pairs which also
mean that the stuff you requested can find it's way back to you]. Apart from
writing useful and interesting stuff that you can analyse to log files [who
visited, when, where from], the bit I get the most use from is the
QUERY_STRING [this is the
"name='Fred'&orderammount='1mil'&ourresponsewas='youbloodybeauty'"].

The CGI'ers and others call this data the "Environment Variables" - from it
being a higher level, a kind of context level, of information around the
real specific stuff you want to do or serve.

3. Perl has scalars, arrays, and hashes. A scalar has values like  'fred' or
6 and has a $ sign in front of the scalar name [e.g. $guysname = 'fred';],
an array is [like javascript] a list of scalars, and hashes are associated
pairs - you know, a list that has
'sex','boy','name','lauri','phone','66554433' in sequence. The list of
scalars that is an array has a name with '@' before it [e.g. @laurisarray].
The list of paired scalars that is a hash has a name with '%' before it
[e.g. %persondetails]. You can get at a scalar in an array by it's position
$laurisarray[0]. The clever little guys who wrote perl also enabled you to
get at the value scalar in hash pairs by using the syntax
$persondetails{'name'}

4. Use (), and {} for flow control and blocks, and ';' for ending
statements, and ',' for seprating list items just like in javascript

5. Perl puts the value pairs that is the environment into a hash and gives
the hash the name '%ENV'.

6. You want the scalar that is the environment variable 'QUERY_STRING' to
grab the data your vistor submitted in the form. You get this scalar by
using $ENV{'QUERY_STRING'}. The most important thing here is to note that
when getting the scalar for the hash [or indeed an array], you need to use
the scalar symbol '$' but hash [or array] name [ hash %ENV scalar member
$ENV].

7. So you can get the string that is your forms submitted name value pairs -
great - but it's got the & and the = still amongst them all. Now perl has
split function and other functions which can get them organised into your
own tailor made hash the query string broken up [recall it started of as a
single scalar of the ENV hash, and now you've cut it up into individual
scalars by turfing the '&' and the '='. BUT YOU DON"T NEED TO DO THIS HARD
WORK. A guy has made a module that you can wack into your script [in much
the same way <!--#include file="myfile.htm"--> puts stuff into you html
file ].

8. Simply, for your second line [after the path to perl line way back in
point 1.] put:

use CGI;

9. This means all the guys code that is his very often used CGI module is in
their for you - just like an inbuilt object in javascript. To get at your
form info, you need to create a new CGI object [familiar, isn;t it] and give
it a name]

$mystuffywuffy = new CGI;

10. Say we use your form data has the format of the hash %persondetails in
3. above, we get say the 'name' value of 'lauri' into a scalar we can play
with by using:

$forminname = $mystuffywuffy->param('name');

11. Now we send this back to the browser. The print statement is what we
use. It knows from the environment the perl script was called where it's
heading the output back to. So the browser can understand what type of info
is coming back it's way, we need to make the first thing printed to the
output conduit [in this case the phone line to our web user] a header and
then the rest [this is not the <head> section of html - though these
boundaries can get blurred with the guys right into this stuff - I think
some stuff like meta tag defaults do come through in the header section we
are talking here (though this happens behind the scenes for us), and you can
over-ride these defaults with your meta tags declarations in the html <head>
section - I think that's the overlap]

print "Content-type: text/html\n\n

12. Now print our piece of data as well

print $forminname;

13. Save the file, place it on your server in your cgi-bin with .pl on the
end of it, make sure your permissions for the file are correct [just get
this stuff off your server guy if you don't know about it], upload a form to
your browser with the text input fields, named correctly as per our data
structure above, fill in the boxes with the correct values, and click submit
[your form will need to have the url for the script in the action attribute
of your form tag] fire away, and the text 'lauri' should appear on your
screen in just the same way as if you loaded a text file just with 'lauri'
in it into your browser it would display that.

At least, this is currently as I understand it.

John


----- Original Message -----
From: Lauri V�in <optima(at)hot.ee>
To: <hwg-techniques(at)hwg.org>
Sent: Thursday, October 05, 2000 4:07 AM
Subject: Re: What Comes Next?


> Hello everybody,
>
> Darrell wrote,
> > I found Perl to be fairly easy to understand (coming from a C
background),
> > and use it often in conjunction with MySQL.  Not being argumentative,
> > Lauri...just a second opinion...:)
>
> To tell the truth, I haven't tried to learn Perl (but some people say that
perl
> is pretty hard), of course, it all comes down to the person. I had no
> programming history, whatsoever and I found PHP had lots of simple and
effective
> functions. PHP is designed for usage on the web, so it should perform Ok.
So,
> PHP is great language plus I consider it to be my stepping stone to other
> programming languages(it's easier to learn something new, when you already
know
> something similar).
> Now, can anybody tell me where I could find tutorials to get started on
Perl, I
> would really like to learn something new, I'm also interested in tutorials
for
> ASP.
>
> Ron wrote:
> > I will almost always say to whomever - design to the standard
> > not the browser. Yes PHP and MySQL are wonderful environments
> > but they are not universally available. CGI is, so knowing
>  > something about it and how it works is important.
>
> Ron has a good point here, you have to have PHP and mySQL installed on
your
> computer, but as John just said: CGI has to be enabled and supported too.
>
> Craig, try to learn as many things as you can (starting with those,
suggested
> here - In alphabetical order?). I personally hope that I know at least 3
> programming languages by the time I'm 18 years old (PHP, ASP and Perl
sound good
> enough! ).
> Reminder: Please send me links, where to start learning ASP and Perl.
>
> Thanks in advance
>
> Yours,
> Lauri
>
>
>
>

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA