Server-side script executed on page load or event, but not SSI

H

Henry

Folks:

I'm writing perl CGI scripts to do some database front-ends, no problem.

However, there's a couple of housekeeping chores to do occasionally: For
example, looking for database updates and downloading them if required.

Thus, on the entry page for my access system there might be a spot that
usually says "database consistent" but will occasionally --every couple of
months-- say "database updated mm/dd/yy" or something like that.

Behind the scenes is a script --perl, I hope-- that runs when the entry page
is loaded which checks to see if it's been run already that day. If not then
it checks the modification date opf the remote database, and ...you get the
picture.

I see how to do this with SSIs, but I'm looking for alternatives.

Yes, I could tack it on to any of the existing cgi's but they already run a
bit long as it is.

Thanks,

Henry

(e-mail address removed) remove 'zzz'
 
J

James Willmore

However, there's a couple of housekeeping chores to do occasionally:
For example, looking for database updates and downloading them if
required.

Use the DBI module.
Behind the scenes is a script --perl, I hope-- that runs when the
entry page is loaded which checks to see if it's been run already
that day. If not then it checks the modification date opf the remote
database, and ...you get the picture.

Yes, but are you looking for something already made? If so, go to
http://freshmeat.net/.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"I am not an Economist. I am an honest man!" -- Paul McCracken
 
H

Henry

Jim:

Thanks for your post on this thread:

Use the DBI module.

I looked at the DBI docs and my head is swimming. I don't think I need
that.

Gee, I'm sorry I used the term 'database'. For what I wanted to ask, it
really doesn't much matter what the raw material is.

What I was trying to do is get a handle on the alternatives for running a
perl cgi script. I know I can do it simply by linking to the script, or by
a form "action". Both these require a user to do something. I'm looking
for running a perl script automagically when a page is loaded.

I believe I understand that I can enable SSI's and have a script run
automagically at load time to fill in content. In fact, the script can do
anything, and that would fulfill my need.

Are there any other perl alternatives? I guess I can run javascript or tcl
from any intrinsic event --per the html 4 standard chapter 18-- but I don't
seem to be able to do this with perl, right? I'm not up to learning yet
another language at this point -- my hands are full with perl.

Yes, but are you looking for something already made? If so, go to
http://freshmeat.net/.

I don't think there's anything at freshmeat.net that will help -- this is
all custom stuff. I keep forgetting to check freshmeat regularly just in
case.

Thanks,

Henry

(e-mail address removed) remove 'zzz'
 
J

James Willmore

James Willmore at (e-mail address removed) wrote on 12/10/03
12:31 PM:
Gee, I'm sorry I used the term 'database'. For what I wanted to
ask, it really doesn't much matter what the raw material is.

Well, in a way it does. If you're reading a CSV file, then the
DBD::CSV module can aid in this task. OTOH, you know what you're
doing with the information better than I do. So, I'll just move on
:)

Are there any other perl alternatives? I guess I can run
javascript or tcl from any intrinsic event --per the html 4 standard
chapter 18-- but I don't seem to be able to do this with perl,
right? I'm not up to learning yet another language at this
point -- my hands are full with perl.

You can use Perl for the task you're suggesting. What are you using
now to display the pages? Are they static? If so, would you be
adverse to having the pages be dynamic on the server side (meaning,
have a CGI script display the pages)? Just off the top of my head,
you could use a single script to execute a command (like finding out
if the pages are up to date), then redirect the user to the
appropriate page. No 'form' required :) That could be one solution.

I know it can be done with Perl. You just need to re-think what you
want and how to get there (outside the box, as it where).

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Hard work may not kill you, but why take chances?
 
H

Henry

James:

Thanks for your reply on this thead:

Well, in a way it does. If you're reading a CSV file, then the
DBD::CSV module can aid in this task. OTOH, you know what you're
doing with the information better than I do. So, I'll just move on
:)

Thanks, I didn't get that kind of meaning from the docs. If I ever have a
standard format I'll know there's help.

What I'm reading is law codes. I've searched all the usual places and some
unusual ones for help parsing these, but without success.
You can use Perl for the task you're suggesting. What are you using
now to display the pages? Are they static?

The base/home/initial page is static html. Everything else is CGI-generated.

If so, would you be adverse to having the pages be dynamic on the server side
(meaning, have a CGI script display the pages)? Just off the top of my head,
you could use a single script to execute a command (like finding out if the
pages are up to date), then redirect the user to the appropriate page. No
'form' required :) That could be one solution.

I know it can be done with Perl. You just need to re-think what you
want and how to get there (outside the box, as it where).

Right, I see what you mean.

Actually, after I sent my last response, I reversed myself (interesting
concept!) and decided, what-the-heck, to try SSIs. Enabled the Apache
server, and Shazam! Full access to perl scripting without the user being
necessarily aware or doing anything specific, which is what I wanted. It's
clear I'll be able to do what I want with this mechanism.

I guess I was reluctant to use SSIs because I thought I recalled some
security issues or unusual complexity, but --upon second view-- this seems
pretty bulletproof and simple to implement.

Yes, it's a question of conceptualization...and knowledge. Partly as simple
as this: Can the index/home/base page itself be (be generated by) a cgi
script, i.e., will Apache look for index.cgi if it doesn't find index.html,
etc.?

Partly an issue of understanding the HTML standards with respect to
scripting, reading behind the lines to understand what scripting languages
are supported by the SCRIPT tag, e.g.

<SCRIPT type="[something]" src="[something else]">

Apparently, JavaScript, VBA, Tcl are options, but perl isn't.

Thanks,

Henry

(e-mail address removed) remove 'zzz'
 
S

Sherm Pendley

Henry said:
as this: Can the index/home/base page itself be (be generated by) a cgi
script, i.e., will Apache look for index.cgi if it doesn't find index.html,
etc.?

Apache *can* be configured to do that.

It's a two-step process - first, you have to configure it to treat *.cgi
files as CGI's instead of just serving their contents statically:

AddHandler cgi-script .cgi

Also, you need to include index.cgi to the list of default documents:

DirectoryIndex index.cgi index.shtml index.html

Having said that, whether your provider has done the above, will do it,
or will let you do it via .htaccess, are all questions I can't answer
for you. :-(
Partly an issue of understanding the HTML standards with respect to
scripting, reading behind the lines to understand what scripting languages
are supported by the SCRIPT tag, e.g.

<SCRIPT type="[something]" src="[something else]">

Apparently, JavaScript, VBA, Tcl are options, but perl isn't.

Strictly speaking, the script element simply defines its contents as a
script - supported languages are beyond the scope of any HTML standard.

In practical terms, some form of JavaScript (AKA ECMAScript) is the only
option that's supported by all script-aware browsers. Even so, not all
browsers are script-aware, and many users choose to disable scripting
for various reasons. There are also many versions of JS in use, so
writing portable JS is a bit of a chore.

Other languages are options for some browsers. IE/Windows, for example,
allows any language that's available via the Windows Scripting interface
- including VBScript, ActiveState's Perl, and many others. There are
other options, such as browser plugins.

In short, if you're writing for a captive audience and you're able to
dictate what browser they use and what plugins they have, you have many
options for browser-side scripting. If you're serving pages to the
general public, JavaScript is your only semi-practical option - and even
JS has issues.

sherm--
 
H

Henry

Sherm:

Thanks for your reply on this thread:

Apache *can* be configured to do that.

It's a two-step process - first, you have to configure it to treat *.cgi
files as CGI's instead of just serving their contents statically:

AddHandler cgi-script .cgi

I'm pretty sure that's already there, enabled.
Also, you need to include index.cgi to the list of default documents:

DirectoryIndex index.cgi index.shtml index.html

So _that_ is how it is done! This has been a minor mystery for me since I
found a list that purported to be the start page file name/search order
followed by _every_ web server...and I quickly found that this wasn't true
with the first server I checked.
Having said that, whether your provider has done the above, will do it,
or will let you do it via .htaccess, are all questions I can't answer
for you. :-(
I can. It's my own server, so I have complete control. (Just what I need,
another responsibility.)
Partly an issue of understanding the HTML standards with respect to
scripting, reading behind the lines to understand what scripting languages
are supported by the SCRIPT tag, e.g.

<SCRIPT type="[something]" src="[something else]">

Apparently, JavaScript, VBA, Tcl are options, but perl isn't.

Strictly speaking, the script element simply defines its contents as a
script - supported languages are beyond the scope of any HTML standard.

Right, that's what I get for looking at a standard, rather than a practical
document. Still, the standard does give examples...for JS, etc. and it
appears these are practical, not theoretical
In practical terms, some form of JavaScript (AKA ECMAScript) is the only
option that's supported by all script-aware browsers.

So it seems. I've found a JS module that did what I needed (collapsing
lists) and I managed to install it, purely by imitation, on one of my pages.
But I don't speak JS, and would not undertake to learn yet another
technology at this point. Since I started learning perl, I've seen an
ever-expanding set of things to learn.
Even so, not all
browsers are script-aware, and many users choose to disable scripting
for various reasons. There are also many versions of JS in use, so
writing portable JS is a bit of a chore.

Yet two more reasons to avoid JS. Well, for the moment, I have a captive
audience for my work (just me) so I can pick the browser. Safari works well
for me.

If I'm tempted to use JS, I've got a colleague who --if I buy him a cup of
coffee, or even if I don't-- will gladly go on at great length about why I
would not, should not. (I didn't tell him about the collapsing lists
exercise -- no sense in getting him exercised.)
Other languages are options for some browsers. IE/Windows, for example,
allows any language that's available via the Windows Scripting interface
- including VBScript, ActiveState's Perl, and many others. There are
other options, such as browser plugins.

OK. I could do that, but I'm already pretty standardized on MacOS X.
In short, if you're writing for a captive audience and you're able to
dictate what browser they use and what plugins they have, you have many
options for browser-side scripting. If you're serving pages to the
general public, JavaScript is your only semi-practical option - and even
JS has issues.

Wow, as a newcomer to this technology (I'm an embedded systems designer) it
seems awfully chaotic. Can you give me a sentence or two on why this is so?
Is it a matter of creativity or commercial interests trying to build in
market share, or what?

Thanks,

Henry

(e-mail address removed) remove 'zzz'
 
S

Sherm Pendley

Henry said:
Wow, as a newcomer to this technology (I'm an embedded systems designer) it
seems awfully chaotic.

It can be. ;-)
Can you give me a sentence or two on why this is so?
Is it a matter of creativity or commercial interests trying to build in
market share, or what?

The 'net standards process essentially broke down in the mid-1990's,
when commercial interests became involved. Before that, there was
certainly some pride and ego involved, but for the most part people
generally worked hard to maintain a high level of compatibility between
various implementations of a given protocol.

With the "browser wars," both NS and MS began introducing new "features"
without even attempting to negotiate how they would work with others'
products. Basically, both companies wanted exclusive control over the
direction of web technology development, which would place the loser in
a position of constantly having to play "catch-up."

sherm--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top