[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
Re: [MacPerl] Introduction
Thankyou for the opportunity to contribute. There are a lot of us alongside
of you who only have the current knowledge to ask questions, and not answer
them. So, as an expert at just starting with perl and macperl, I've got
some pointers [or should I say references ;)].
You could do this:
1. Buy or go to the link [see previous message] for Macperl - Power and
Ease, and browse it from cover to cover.
2. Set yourself a task list of say five simple little programs. Then
motivate and discipline yourself to complete these tasks. This would
involve looking at your books, asking questions here, and of course coding
time.
3. Photocopy or printout from either one of your books or a source on the
net or the documentation that comes with the perl files you put onto your
computer the stuff that gives lists of reserved words, operators, functions
etc, and put it on your coffee table.
4. Along the way you might want to go to
http://webreview.com/wr/pub/98/08/21/perl/index.html .
I find I have to force myself to doing some regimented learning
sometimes...starting with page one and working my way through the
books...not thinking about my project, just ##learning##, taking notes,
doing the examples. I usually choose a chapter or online resource that
deals with an area I realise I need.
I don't get caught up on the modules just yet. I figure that I'll get to
them in good time. However, as I go along if I get pointed in the direction
of a module [like a response from this mailing list] I'll probably try and
use it and ask questions later.
My ISP is apache running on linux [which I'm told is very similar to unix].
These are the things I have found so far, after being pointed in the right
direction by responses from this list.
* permissions ... to get the ball rolling put all files in your cgi-bin and
set all permissions on [I do this with my ftp program called fetch] ...
once it's working, play with the permissions and put non script files in
other folders and see if you can aceess them with your scripts ... don't
forget your folders have permissions too.
* to go up a folder in a file path reference you use ../. So if you had a
root folder called mysite, in it being cgi-bin and myfiles, to open a file
in myfiles with a script in cgi-bin you would use something like:
open (LANDING, '<../myfiles/landing.txt>') or die 'The landing file did not
open'
* that you can do an awful lot with just a couple of perl bits:
- god bless:
use CGI::Carp 'fatalsToBrowser';
- the following will send whatever follows it back to the person on the
interent calling the script:
print "Content-type: text/html\n\n";
- this will print the five lines **exactly** as is:
print "<<UPTOHERE";
this is line one
this is line two
three is now
four and I don't have to worry about the \n stuff
line five - yeh yeh
UPTOHERE
* The CGI bit:
[as I currently understand it and if I'm wrong someone correct me please]
when an input tag of type submit [submit button] of an html form is
clicked, then what happens is that a record [a sequence of characters sent
in an order that means name value pairs stay together in a known pattern
and seperating characters that means they can be seperated by a program
like perl] is sent from the browser to the server, and what's in this
record [the field names and the field contents if you like] is as per the
CGI standard.
The great news for us is that this is available in perl in a hash called
%ENV, . So to get the contents of a particular field in the CGI record that
got passed across on submit, we just have to know what to put in the braces
bit of $ENV{...}.
Now one I do know is $ENV{'QUERY_STRING'} [perl case sensitive, single
quotes], because this is the one that contains the text that users typed
into your input fields, along with the names that you gave those input
fields.
So say you had the following html page on your website in a folder
alongside your cgi-bin folder:
<html>
<head>
<title>Form To Send String</title>
</head>
<body>
<form method="get" action="../cgi-bin/incame.pl">
<input type="text" name="client">
<input type="text" name="page">
<input type="text" name="date">
<input type="submit" name="submit form">
</form>
</body>
</html>
and in your cgi-bin you had the script called incame.pl[with permission set
using ftp program to all for all if permissions giving problems]:
#!/usr/bin/perl
use CGI::Carp 'fatalsToBrowser';
# grab the query string
$input = $ENV{'QUERY_STRING'};
# show the query string
print "Content-type: text/html\n\n";
print<<'HTML';
<html>
<head><title>This Was The Input</title></head>
<body>
HTML
print $input;
print '</body></html>';
and you click the submit button after downloading the form into your
browser from your website, you should see the querystring as it was
received and after perl seperated it out from the rest of the CGI string
that was sent originally.
So then you script can do stuff with the querystring, in this case named
$input.
If you wanted to see what else was in the CGI string I guess you could just
print the contents of %ENV. What would happen if you replaced $input with
%ENV in the print line:
print %ENV;
Does that work?
What about if once you grabbed the query string you put:
@doesthiswork = %ENV;
and then in the print line put:
print @doesthiswork;
Does that work?
* cgi.pm
I haven't used it, but I would assume it does things like strip the name
value pairs provided by people filling out your forms obtainable in less
steps, and maybe picks up on differences presented by different operating
systems or browser types, and does some html for your output to the client
for you, and lots more because it seems very popular.
This may be a bit more elementary than you require. If it is, I mean no
offence.
A question for you ... "what do you mean by OO aspects of perl 5"?
Regards ... John
===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org