Differences between Perl & PerlScript

Basically both, Perl & PerlScript, are commonly known as Perl. Perl is quite some years old, but regained popularity in recent years for CGIs used on local machines, in intranets or the world wide web mostly in conjunction with HTML.
The reason is that HTML - even if used in combination with JavaScript - is a a very static and poor equipped system. When using CGI (common gateway interface) techniques, websites become more like applications; they are able to store and retrieve data, manipulate graphics, generate dynamic webpages, do file-access statistics ecetera. CGIs work in coop with a webbrowser and adapted HTML documents. While those CGIs may be written in any programming language, Perl is the most famous one cos it is best for manipulating strings. Stringmanipulation is important for inserting data or generating HTML docs and to process data in streams / files. Also, Perl offers strong interfaces for internal variable querying and more.
While "real" Perl may be written in objective style (OOP)and compiled to binary executables, the smaller version called PerlScript is the one most used as CGIs. The difference to Perl is that PerlScript will be stored and processed in a source code state, thus not compiled. Although allowed and possible, PerlScript is commonly not object oriented and much more simplier than the binary brothers. Now let us take a look on how PerlScript is usually used.

PerlScript in action

Imagine a user surving on the internet. He / she visits a website containing a survey poll on the visitor's age. The site asks "How old are you?", below there is the actual statistic in percent along with a graphical showing followed by five checkboxes where the visitor can select (e.g. <18; 18-25; 26-35; 35-50; >50). If the user clicks the submit button, his selection is sent to webserver that contains the HTML pages as well (that is not a must-be, btw.). This is the point, the PerlScript takes action (in fact, it has done already something for the visitor, but see...).
The server receives the poll and passes it to the CGI which runs the PerlScript. The script has two ways of getting the polled data, depending on the send method specified in the HTML document:
a) GET: the data was passed by using the URL of the script, similar to command line parameters, e.g. http://www.example.com/cgi-bin/poll.pl?sex=m&age=18to25 . As you can see, the part before the quotation mark is the location, everything after it is the data in form of name1=value1&name2=value2. Thus every value is identified by a name, a new dataset is distinguished by an ampersand.
b) POST: data is posted via STDOUT / STDIN and allowes more data. Remember that an URL may not contain more than 255 characters, the GET method is not that flexible. POST allows much more data to be passed and is often used for guestbooks.
Now that the scripts can obtain the parameters, it will open a database file to store the information. When done, it generates a HTML document from given specifications (e.g. an existing HTML doc where it has just to replace special IDs with the actual content) or by hardcoded HTML tags inside the script. In our example, the script has also the ability to manipulate. For this purpose, it can call standard routines in an external Perl library and insert the result in the HTML site. All the data will be passed back via STOUT to the user's webbrowser to show the update. But what role has the webserver?

Webservers

A webserver in general is an interface between a local computer and special web services. For example, if you want your machine to be a server acessible via an intranet, you run a webserver application such as Apache or Xitami. Those applications map local filepaths to public ones, manage user rights, coordinate CGI accesses and offer web services like http, ftp, telnet etc. Thus, the file C:\Data\Web\HTML\MyWeb\index.html or /usr/home/blazko/web/html/myweb/index.html may become this form: http://blazkostation/index.html for outside computers. You see, the webserver app made two things so far: it provided access via the htt protocoll and mapped a local path to a public one.
But the main reason why talking 'bout webservers here is that you need one to develop PerlScripts designed for HTML purposes on your local machine. If you launch a PerlScript using a HTML formular without using a webserver, the browser will not run the script directly but asks if to download the script as a file or if to run it directly. If confirming to run it, you will see that the command line window will pop up printing the script's output - but you will not see the result page in your browser. If accessing it via a webserver, this whole thing will run the way designed to be. Thus, before starting to work with CamelRider, please get a webserver and Perl and then configure all tools (including CamelRider). Where to obtain the items needed, see bottom of page. How to configure CamelRider, see  Chapter 2.0: Basic configurations.

Resources

To work with Neveprise CamelRider, you need both - the Perl interpreter that runs your scripts, and a webserver that allows you to test / verify websites that work in conjunction with PerlScripts. The webresources shown here are my favourites, you may investigate the www for your favour.

Webserver	Perl interpreter
Xitami for Windows	ActiveState Perl
www.xitami.com or www.imatix.com	www.activestate.com
Perl information / references / links (CPAN)
www.perl.com

Back: 1.1 Introduction

Next: 1.2 Basic parts of the IDE