Company web-site (all perl CGI) re-design, suggestions?

J

Justin C

The in-house web-site is about twenty pages. Most of
the pages are the front end to perl programs that
perform various tasks. The index page at the base URL
contains links to each of the other pages. The pages
each have their own directory, and are index.cgi so
that, from the top level, the link is self explanatory,
eg: http://inhouse/postage_calculator/.

Every time a new program is added (or a new static
page), a directory is created and a standard template
is copied to the directory. The template takes care of
layout, template items, linking style.css, and looks
for either body.txt or program.pl in the current
directory which then takes care of the pages purpose.

The site is getting complex, several modules have been
written to take care of common tasks (database look-ups
mainly). The more I look at the site the more I know
there must be a better way, it's time consuming to add
new modules to each of the existing templates, and
check that none have been missed, and that nothing gets
broken by the addition.

I'm sure I should do away with the 'site' concept, the
whole pages and directory tree structure, and have just
one program at the base URL, and that one program call
methods for whatever task is requested. I think I
should also implement a system by which the program
remembers data submitted between calls rather than
relying on hidden form fields, or a tmp file and
relying on the infrequency of use to prevent requests
clashing (user 2 getting the results of user 1's
query).

The current site uses the CGI module. I believe this is
no longer flavour of the month. It has served well
enough, but there has been some serious head-scratching
trying to bend it to fit some of my requirements, I
look forward to learning something new. I think I could
make CGI fit, and I am familiar with it, but if there's
a better way then that's what I'd rather be doing, as
much for learning something new as for doing this
'right'.

I welcome any suggestions, or pointers to
documentation, for where I might start or how I might
proceed.

I have considered CMS for this, but that doesn't seem
as appropriate for programs, which tend to hang around
for years, as it does for 'news' stories which tend to
update often. I'm very happy to be disuaded of this if
someone thinks I should be going with CMS.

Thank you for any comments, suggestions, pointers to
reading matter.

Justin.
 
C

ccc31807

On Monday, December 17, 2012 9:24:00 AM UTC-5, Justin C wrote:

Justin,

I've never down any real big sites, but I've done a bunch of smallish sites, some with as many as 50 pages, almost all of them (if not all of them) are interfaces to databases.

I use CGI and it's done every thing I've asked it to do. I have learned to do it the way i describe below mostly by trial and error, and by writing a lot of very bad code over the years. I am completely comfortable with this approach.

The only HTML page I write is the main entry page to the 'site.' All the other HTMl 'pages' are dynamically created from the query parameters passed in by the user and the content in the database.

All of the HTML content, and graphical content, I keep in a database, and Iwrite a console for the maintainers to maintain and update the content themselves.

For example, suppose I have a table that looks like this:
create table HTML (
page text primary key,
content text );

The content might look like this in CSV:
"products/","Welcome to our products page."
"products/office/","Here are our office products."
"products/cleaning/","Here are our cleaning products."
"products/books/","Here are our books."
"staff/","Meet our staff."
"staff/sales/","Our friendly sales people."
"staff/techs/","Our competent technical people."
"staff/management/","Our superior management team."

You might get your navigation device by something like this:
select page from HTML;
and then parse the keys and create your various menu bars.

When your user clicks on a link, you generate a query like this:
select content from HTML where page = 'staff/sales/';
and then use your Perl script to spit out the HTML content to the web server.

Typically I would modularize the app, have a SQL module, an HTML module, and maybe a couple of others. Mostly, the 'main' script is very simple and just calls functions.

Your script might look a little like this:
#! perl
use strict;
use warnings;
use CGI;
use SQL; # a custom module
use HTML; # a custom module
my $page = param(page');
# these functions will return a hash reference that contains the data
my $nav = SQL::get_nav($page);
my $content = SQL::get_content($page);
HTML::print_header($page);
HTML::print_nav($page);
HTML::print_content($page);
HTML::print_nav($page);
HTML::print_footer($page);
exit(0);

For an illustration of what this would look like, go to
http://mupd.org
Look at the URLs displayed in the address bar. There are no HTML pages because there's no HTML. Every page is dynamically created from the links clicked by the user.

This probably isn't the best way to do it, but it's cheap, fast, and takes the burden of maintaining the site off me. And yeah, I know the site isn't anything to write home about, but I don't hold myself out as a web design artist, just a database guy who writes front ends to databases.

CC.
 
J

Justin C

On Monday, December 17, 2012 9:24:00 AM UTC-5, Justin C wrote:

Justin,

I've never down any real big sites, but I've done a bunch of smallish sites, some with as many as 50 pages, almost all of them (if not all of them) are interfaces to databases.

I use CGI and it's done every thing I've asked it to do. I have learned to do it the way i describe below mostly by trial and error, and by writing a lot of very bad code over the years. I am completely comfortable with this approach.

The only HTML page I write is the main entry page to the 'site.' All the other HTMl 'pages' are dynamically created from the query parameters passed in by the user and the content in the database.

[snip]

Thank you for the reply, CC. I wanted to try one of the web-frameworks
to further my education - though I'm sure I would have done that your
way too.

After spending a day with a book on Catalyst and not seeing how what
they were talking about related to what I wanted to do, and running
through their tutorials... which wouldn't work! I looked a little deep-
er into Mojolicious, and within five minutes I had a working web-app,
and can already see how I redo our site using this.

I'm probably going to run into major obstacles, but this looks like a
much shallower learning curve, rather than the brickwall I found with
Catalyst.

Justin.
 

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,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top