marlin has asked for the
wisdom of the Perl Monks concerning the following question:

Hello!

I am very new to Perl and CGI scripting. I know a fair bit of the Perl language but I'm having trouble putting together a CGI-driven website.

How are CGI-run websites usually organized? Is there a single script that is called when a user visits the website, and then that single script will perform all the website functions like accepting inputs, writing to a database and generating html for all the pages?

Or, is there a directory of perl scripts that are embedded into the html pages of the website? And they can each pass info to each other?

Currently I have it set up so that index.html has a Perl script embedded in the center and it outputs all the main content, but how do I make it clear the page or switch to another script, and is that even a good idea?

My goal is to make a server-side Perl program that will accept inputs from a web page, do several computations with these inputs, and then post the results in HTML (and eventually SVG) and continuously do this on the same page without having to refresh.

CGI still exists, and hasn't died yet. That's about all that it has going for it though. Nowadays MVC frameworks are all the rage. Mojolicious is great. But everyone has their favorites, including Dancer, Catalyst, and even grand-daddy, CGI::Application.

With a framework like Mojolicious the process is pretty simple. Take a look at the documentation on the link I provided and see if that seems easier.

Two disadvantages that plain old CGI have are that every time a new hit comes in the Perl interpreter has to fire up all over again, which takes time. And second, non-trivial applications have a habit of becoming too complicated from a coding standpoint since plain old CGI.pm doesn't do anything to help promote separation of concerns (Model, View, Controller).

As others said, if most of your pages will have dynamic content, look into frameworks. To answer your first questions, it varies. Some people have a single CGI that runs everything, calling functions in other files depending on the pathinfo (the way PHP apps like Wordpress or Drupal run everything through index.php). Others use multiple CGIs, each for a different function. Others use SSI, which allows you to embed Perl scripts (or other executables) in HTML, but in a pretty inflexible way, so that's not common. But look at frameworks.

As for your last requirement: if you want a portion of a page updated regularly without refreshing the whole page, you'll want to look at client-side solutions like Ajax. You can push updates from the server side with Apache's nph-script method, but I've always thought that's pretty ugly. You can also send HTTP headers or meta tags that will cause automatic refreshes, but then you're refreshing the whole page, which you said you don't want. (Those might work within an iframe to do part of a page; I'm not sure about that.) But sites that do dynamic updates to individual divs on the fly use Ajax or something similar, to fetch new content and change just what elements need to be changed. I think all the common frameworks come with a fair amount of support for Ajax built in, too.

"Do not do a thing already done." As "interesting an exercise" as it may or may not be, when you know that you are following in a footpath that has been trod by literally tens of thousands of people ahead of you, you do not want to follow in their footsteps: you want to climb upon their shoulders.