Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Design vs. Code vs. Maintenance

by BBQ (Deacon)
on May 17, 2000 at 18:34 UTC ( #12094=perlquestion: print w/replies, xml ) Need Help??

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

Design vs. Code vs. Maintenance. I seek the best-practices wisdom of fellow perl monks on a semi-technical issue. Picture the following scenario:

We have 1 Project manager, 4 HTML designers/artists, and 2 perl programmers. The project manager knows close to nothing about perl, and the designers/artists don't want to learn (I can see their point). The programmers are stuck with the job of maintaining fancy sites written by people that have very little regard for there pain-stricken job of taking all the HTML and making functional code out of it. (The 2 programmers work with assorted types of databases and DBI.)

For now, I've managed to convince the designers to write out some special tags where data should be replace in the HTML, thus making it possible to extend the workflow of things just a bit. Our HTML comes out looking something like this:
<tr> <td><font fancy stuff>Name</td> <td><font fancy stuff> {name} </font></td> </tr> <tr> <td><font fancy stuff>Address</font></td> <td><font font stuff> {address} </font></td> </tr>
Then we (the programmers), place this template on the server and do something in the lines of:
  • connect to a database
  • do database stuff (inserts, selects, etc)
  • parse the template file looking for {variables}
  • print everything back to the client
So far, so good? My question (finally) is,

"Considering that most webhosting companies do not offer solutions such as embperl, Mason, Apache::ASP or others of the sort, what is the most efficient way to work with, build and maintain these websites?"

TIA

Replies are listed 'Best First'.
RE: Design vs. Code vs. Maintenance
by lhoward (Vicar) on May 17, 2000 at 18:42 UTC
    If you can get HTML::Template on your server it supports almost exactly the "parse template/fill in content" methodology that you've just described (only the tag format is slightly different):
    <TMPL_VAR NAME=PATH>
    In response to your original question :
    Considering that most webhosting companies do not offer solutions such as embperl, Mason, Apache::ASP or others of the sort, what is the most efficient way to work with, build and maintain these websites?
    I would not let "webhosting feature availability" influence my decisions in any major way when it came to features that would severly affect the design, development, maintenance, architecture, scalability, and performance of a site. I first decide what are the right tools to use to make the site then ask who can provide me with these tools. If a company can afford a 7 person team to develop a website then they can surely afford to get server(s) configured they way they require to run the site. You are already placing requirements on the server by making the choices of perl, DBI, and a database (w/ apropriate DBD module). Requiring a few additional perl or apache modules is not asking too much. Making an architectural decision of such importance based on provider availability could lead to a support/maintenance nightmare later on. It is well worth it to do things properly up-front to save yourself pain later on. Choosing an inferior tool just because its convenient is not the right answer : I don't see any saws near-by, but I do have a bunch of hammers, so why don't I use one of them to cut this 2x4.

    Webhosting is a competitive market and it sounds like you are developing a non-trivial site. Hosting your site could mean a lot of income to whichever web-hosting provider you use. They should be willing to provide you with the tools that you require in order to get your business. If "most webhosting companies do not offer" what you need seek out the ones that do and give them your business. Other developers will make the same choices as you and the providers that offer better services/features to the site development/maintenance team will flourish.

      Yeah, I think I should have specified why my worry about webhosting providers. You see, many of our customers already come to us with a webhost that they have used in the past and are happy with. Its my company's policy not to vouch for other company's services, so we tend not to try and push them away from a service that they are already happy with.

      In some cases (our larger, corporate) clients own their own servers, but then its likely that I'll have to get it through to the thick-skulled-dinosaur-it-manager that compiling DBD::Oracle requires that you have at least Oracle client installed on his HP-UX (get the drift?).

      Bottom line is that unfortunately I am not always able to choose out of a vast quantity of hosting options, and that's why I got stuck with my MakeHTML($template,%HASH) solution. :o/

      Thank you for the great advice on HTML::Template, I've skimmed through and seems to be exactly what I was in need for! (and my most common webhost, HWay, has it in their module list)
        I understand getting stuck with a less-optimal solution because of choices made elsewhere. About all you can do it inform the client of the ramifications of their decision and prepare.

        In the first case I would handle it like this. Tell the client company:

        Since your current webhost doesn't support A, B, or C we can develop your project in X weeks and it will take about Y effort to support in the future. It will scale like Z. If you find a webhost that supports A, B, and C then we can implement it in T weeks and it will take about U effort to support in the future and it will scale like V.
        Break it down in such a way that both their operations staff and accounting departments can both understand the ramifications of the choice they've made. If they choose to stay, at least they know what tradeoff they made (and hopefully they'll come back to you when they realize the error of their ways). Also, if you can get your company to change policies and start recomending a (or some) particular webhost(s), you may be able to cut a deal w/ the webhost that would let the clients get a lower rate (since you'd be bringing them in in bulk).

        In the second case (and I've been in that EXACT same spot before w/ HP-UX and Oracle even). be sure you include in your specifications details requirements of what they must have installed (preferably in an early spec that upper-managemet signed-off on). Make sure this is widely distributed to all parties related to your project in the client company. Make sure you are ready so if it comes down to the dinosaur manager problem you can place blame squarely on his/her shoulders and show him/her that upper management has already signed-off on it. It still isn't a fun fight to have, but being prepared can make it an easier win.

      I too agree with lhoward about both HTML::Template and his views on choosing webhosts. I had been using custom "special" tags and then parsing this template. I've now begun using HTML::Template and am quite happy that I am. In addition to generally making HTML editing MUCH easier, it also allows for loops and some other nifty controls. Good luck, Doran
Re: Design vs. Code vs. Maintenance
by infoninja (Friar) on May 17, 2000 at 19:41 UTC
    You may also want to check out CGI::FastTemplate. I've been quite pleased with it. I agree with lhoward - if you're paying for webhosting, you should be able to specify a few perl modules for your site(s) - if your current hosting company won't comply, you should be able to find one that does pretty easily.
      Thanks for the suggestion but, that won't work...

      You see, the main idea behind the templates is to allow my designers to keep to HTML and not have to even think about splitting a file up into head.tpl, foot.tpl. row.tpl and so forth. Come to think of it, I don't think I would use it even if I where doing all of the work myself because the of the template mess you might get into when doing a complex designed site. Keeping track of each tpl file would become, as lhoward put it, a maintenance nightmare.

      But thanks anyway.
Re: Design vs. Code vs. Maintenance
by ikitat (Acolyte) on May 17, 2000 at 19:08 UTC
    You may want to check out the list of ISPs supporting mod_perl at apache.org
Re: Design vs. Code vs. Maintenance
by chromatic (Archbishop) on May 17, 2000 at 21:02 UTC
    I'm working on a couple of sites with similar setups. What I've done is to commission an overall design for all of the pages. Then, I abstract out the parts that have to change for each (a navigation box, depending on where you are, a main graphic, the text of a separate page, and so forth). I break things down into templates on my own, and store those in a database.

    I also store all of the page content in the database. Now there's also a web interface (with permissions and security checks) where various people can update the content.

    Instead of building pages dynamically from the web server, I have a backend program, either run from cron nightly or activated automatically which walks through the hierarchy and updates any pages that have changed. I can afford to be a little bit inefficient with the substitution and transformation, because it doesn't happen in real time.

    This seems to work pretty well for sites of only a couple of hundred pages, with only a few changes every day. Scalability isn't on my list of worries right now.

      I've used that exact same setup in the past for larger websites (+500 pages), in combination with SSI for header/footer stuff. I'm not terribly worried about the sites that need constant work or are large projects where we have to allocate alot of programming man-hours, since those usually have small design update issues.

      The amount of effort put into changing 1 single script tends to be alot more than changing the entire site look and feel, and that's where we hit the hard cold bottom. Smaller sites shouldn't require a programmer's man-hour (which is more expensive than a HTMLers man-hour) when the maintenance is purely synthetic.

      I'm rambling... What I wanted to say is yeah, I like your setup and I've used it in the past, but I'm looking for a solution for the smaller, everyday sites (40 pages tops).
RE: Design vs. Code vs. Maintenance
by Anonymous Monk on May 17, 2000 at 22:44 UTC
    My solution has been CGI::FastTemplate. If the site has a consistent look and feel that you are trying to maintain, have your HTML guys create an html file that looks like it "should", and put a 1 element table in the center. Its contents will be '$TEMPLATE'. Using CGI::FastTemplate, the code can look like:
    use CGI qw/:standard/; # for html shortcuts
    use CGI::FastTemplate;
    # code here
    # creates an HTML string called $template, i.e.
    
     my $template =  table({-width => "641",
                     -align => "center",
                    },
                    Tr(td(
                          font({-color => "#3399CC"},
                               "There were errors in the form input:")),
                          (map {h2("$_:"), h3(ul( map (li(i(mapfieldname($_))), @{$errors{$_}}) ))} keys %errors)
    
                         )));
    
    # and now show the results
    my $tpl = new CGI::FastTemplate("/home/httpd/html/templates");
    $tpl->define( finished => "output.tpl" );
    
    $tpl->clear_href;
    $tpl->assign( { TEMPLATE => $template } );
    $tpl->parse( FINISHED => "finished" );
    print header();
    $tpl->print;
    exit;
    
    After that, your scripts will only be responsible for printing what is relevant to you, w/o having to try and write too much html (that's what the HTML guys are there for, right? :-). If you really want to go there, you can even have the HTML guys use CSS and reference the styles in your (script generated) output.
Re: Design vs. Code vs. Maintenance
by swiftone (Curate) on May 17, 2000 at 23:07 UTC
    Unlike the many HTML::Template and CGI::Fasttemplate followers, I designed a similar system using Text::Template. My site, however, involved only a few templates for many layers. (e.g. Home page, 2nd-level pages (any any deeper)). The goal was to separate the site into three parts: Content, for non-computer people to edit. TEmplates, for interface people to edit, and code, for programmers.

    It works like this:

    • I have a database holding the info for all the pages (title, name, Keywords for meta tags, and parent-child relationships.) The database isn't vital to the concept, but lets us modify the site structure easily.
    • I have a small script that consists of two subroutines, one that loads all variables for a given page from the database, and another that uses Text::Template to load a given file. I use the prepend option of Text::Template to load that template with this very script (So my templates can in turn call templates, etc)
    • Actually, I have several variants on #2, each with a slightly different purpose. One writes an HTML file (or multiple files). One displays the content parsed into HTML, but without writing a static HTML file, another does the same thing, but wraps the text of the content in TEXTAREA fields so it can be edited, etc..
    The result is two-fold. The goal of separation has occured, allowing us to quickly re-build and add onto parts of the site. Also, because there is a difference between the base content files and the actual "built" HTML files, we have an effective Staging Area for content to be reviewed and approved before going Live. Combining this last part with some simple RCS has given us a measure of control and version history as well. Also, we can simply point our build script at a different set of templates, and generate a sub-site that is (for example) for text-only. No need to duplicate content. In case you are curious, Content pages look like this:
    <!!&SiteBuilder_Load($Header,$ID)!!> Uneditable content <!!$BeginText!!> Editable Content <!!$EndText!!> more uneditable content <!!&SiteBuilder_Load($Trailer, $ID)!!>
    (<!! and !!> are the tags I choose for Text::Template)
Re: Design vs. Code vs. Maintenance
by comatose (Monk) on May 17, 2000 at 21:43 UTC

    This probably isn't the answer you're looking for either, but have you thought about using PHP? We use PHP quite a bit because:

    1. It was easy for me to learn, already knowing Perl.
    2. It performs reasonably well in CGI or Apache module mode.
    3. Relatively fast development cycle.
    4. Many hosting providers offer it without significantly increasing costs.
    Of course, it has its drawbacks.
    1. No CPAN
    2. Not quite as elegant as Perl
    3. Not as good at regular expressions
    4. Not Perl :)

    PHP has "include" functions for importing the things you want to use over and over. We use includes for the headers and footers so that the page content is separated from the page navigation and look-and-feel..

    I would not recommend PHP for anything where you want to have some very powerful functionality and have a tight deadline. It can be quite tedious to do serious application development...at least in comparison to Perl.

RE: Design vs. Code vs. Maintenance
by Anonymous Monk on May 17, 2000 at 22:42 UTC
    My solution has been CGI::FastTemplate. If the site has a consistent look and feel that you are trying to maintain, have your HTML guys create an html file that looks like it "should", and put a 1 element table in the center. Its contents will be '$TEMPLATE'. Using CGI::FastTemplate, the code can look like:
    use CGI qw/:standard/; # for html shortcuts
    use CGI::FastTemplate;
    # code here
    # creates an HTML string called $template, i.e.
    
     my $template =  table({-width => "641",
                     -border => "0",
                     -cellspacing => "10",
                     -cellpadding => "0",
                     -align => "center",
                     #-height => "734",
                     #border => 1
                    },
                    Tr(
                       td(
                          h1({-align => 'left'},
                             #img({ -src => "/anim_logo.gif",
                                   #-width => "375", -height => "56"
                             #    }),
                             br,
                             font({-color => "#3399CC"},
                                  "There were errors in the form input:")
                            ),
                          (map {h2("$_:"), h3(ul( map (li(i(mapfieldname($_))), @{$errors{$_}}) ))} keys %errors),
    
                          h3("Please click your ",
                             a({href => "javascript:history.go(-1);"}, 'BACK'),
                             " button and correct the pro
RE: Design vs. Code vs. Maintenance
by cei (Monk) on May 17, 2000 at 23:51 UTC
    I used to do this all the time by hand without using any CPAN modules. Here is my method:

    1. I named my html templates with a .htmlt extension, so I'd know they were templates.
    2. My variable placeholders in the template files were designated as allcap names of their matching perl variable name. Example, if I had $title in my .cgi, then I'd have a $TITLE in my .htmlt.
    3. In my .cgi, I'd have the following:
      open(TEMPLATE, "mypage.htmlt") or die "can't open mypage.htmlt: $! +"; local($/) = undef; my $template = <TEMPLATE>; close(TEMPLATE); $template =~ s/\$TITLE/$title/g; print "Content-type: text/html\n\n"; print $template;
    That's about all it took. No modules, no special installs or permissions with the ISP.
      Yeah, I know what you're saying... This is what I have (and what I'm trying to run away from):
      # parses HTML files as templates ################################################# sub MakeHTML { my ($file,%HTML) = @_; my ($line,$tag,$html); # open HTML file open(READ,$file) || return(0); foreach $line (<READ>) { foreach $tag (keys %HTML) { # substitute tags $line =~ s/\[$tag\]/$HTML{$tag}/gi; } # gather parsed HTML $html .= $line; } close(READ); return($html); } # assign things like $STUFF{'myname'} = 'John Burbridge'; $STUFF{'myage'} = 26; # then print it my $html = MakeHTML('/path/to/template.htm',$STUFF) or Errors('couldnt parse the template'); print "Content-type: text/html\n\n"; print $html;
      and the template file would look like this:
      <html><body> My name is [myname] and I am [myage] years old. </body></html>
      Sure it looks pretty simple and handy at 1st glance, but beleive me: ITS A BAD HABIT. I had to learn this the hard way...
Re: Design vs. Code vs. Maintenance
by elwarren (Priest) on May 17, 2000 at 21:39 UTC

    To answer your final question: I once wrote some scripts that were very similar to the html::template concept, but I did not use it in a cgi context. I kept a mirror of my html tree, except all the files were templates. A short little find script would run through all the directories, generate the static html pages based on the templates, and finally move them all into the live html tree. You then have a database driven site without the database!

    As an added bonus, it was quite easy to move the site from the old style generated static pages to a live database driven site. The output just goes to the screen instead of the file.

    I think this was what you were asking, hope it helps.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://12094]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2022-10-07 03:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My preferred way to holiday/vacation is:











    Results (29 votes). Check out past polls.

    Notices?