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

Discussion in 'Perl Misc' started by Henry, Dec 10, 2003.

  1. Henry

    Henry Guest

    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

    remove 'zzz'
    Henry, Dec 10, 2003
    #1
    1. Advertising

  2. On Wed, 10 Dec 2003 04:19:06 GMT
    Henry <> wrote:
    > 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
    James Willmore, Dec 10, 2003
    #2
    1. Advertising

  3. Henry

    Henry Guest

    Jim:

    Thanks for your post on this thread:

    in article , James
    Willmore at wrote on 12/10/03 12:31 PM:

    > On Wed, 10 Dec 2003 04:19:06 GMT
    > Henry <> wrote:
    >> 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.


    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.


    >
    >> 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/.


    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

    remove 'zzz'



    >
    > HTH
    Henry, Dec 11, 2003
    #3
  4. On Thu, 11 Dec 2003 16:57:01 GMT
    Henry <> wrote:
    > in article ,
    > James Willmore at wrote on 12/10/03
    > 12:31 PM:
    > > On Wed, 10 Dec 2003 04:19:06 GMT
    > > Henry <> wrote:


    > 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?
    James Willmore, Dec 11, 2003
    #4
  5. Henry

    Henry Guest

    James:

    Thanks for your reply on this thead:

    in article , James
    Willmore at wrote on 12/11/03 9:28 AM:

    > On Thu, 11 Dec 2003 16:57:01 GMT
    > Henry <> wrote:
    >> in article ,
    >> James Willmore at wrote on 12/10/03
    >> 12:31 PM:
    >>> On Wed, 10 Dec 2003 04:19:06 GMT
    >>> Henry <> wrote:

    >
    >> 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
    > :)


    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.
    >
    >
    >> 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?


    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

    remove 'zzz'

    >
    > HTH
    Henry, Dec 11, 2003
    #5
  6. Henry wrote:

    > 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--
    Sherm Pendley, Dec 11, 2003
    #6
  7. Henry

    Henry Guest

    Sherm:

    Thanks for your reply on this thread:

    in article CM4Cb.12633$, Sherm Pendley at
    wrote on 12/11/03 12:50 PM:

    > Henry wrote:
    >
    >> 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


    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?
    >
    > sherm--


    Thanks,

    Henry

    remove 'zzz'
    Henry, Dec 11, 2003
    #7
  8. Henry wrote:

    > 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--
    Sherm Pendley, Dec 12, 2003
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fred
    Replies:
    2
    Views:
    1,070
    Craig Deelsnyder
    Jul 12, 2004
  2. Cédric Rossé
    Replies:
    1
    Views:
    528
    Cédric Rossé
    Nov 9, 2004
  3. Replies:
    0
    Views:
    349
  4. Replies:
    2
    Views:
    355
  5. Sunny Mohan
    Replies:
    0
    Views:
    210
    Sunny Mohan
    Apr 5, 2004
Loading...

Share This Page