Actually if you look closely, I made sure to make my statement not a categorical statement. That is why I said "most", not "all".

But to the real question. In this specific case I definitely disagree. A set of glorified marked up HTML pages that parallel a set of CGI scripts does not necessarily a maintainable design make. Suppose, for instance, that you are putting together website where several of the pages have a large chunk (say about a third) of the page in common. What approaches would you take? Well here are some options:

  1. Maintain the HTML for those pages as HTML.
  2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages.
  3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common.
Here are some of the maintainability implications.
  1. Maintain the HTML for those pages as HTML. Well HTML has no real include mechanism so that common chunk needs to be maintained in parallel between those pages. If that chunk includes dynamic content, this could be an ongoing issue. But you do preserve the ability to use standard HTML WYSIWYG tools to modify the page.
  2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages. Tools like the Template::Toolkit make this easy and natural to do. You now lose the maintainance problem of maintaining pages in parallel. However you have also lost the ability for designers to conveniently use WYSIWYG tools on your pages as a whole (they can on each component, but more knowledge is needed to work this way), and now people maintaining the HTML or code needs to understand the layout of your templating system to work on your site.
  3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common. Again you lose the maintainance problem of maintaining pages in parallel. On the flip side you now have code and HTML mixed together. But you don't have the conceptual overhead of a template system to work with and the mix of skills required is fairly readily available.
IMHO any one of these solutions could turn up best in a real project depending on the skillsets of available developers, and the scope of what needs to happen. I would be inclined to go with the first in a small site where layout developers have considerable input and want to keep changing the look and feel of the site. I would be inclined to go with the third in a small site where the look and feel of the site was pretty much fixed but there are a lot of developers and a large variety of dynamic content. (Pages almost the same but different data sets and different fields driving it.) I would want to go with the second for any significant site with both ongoing data and design maintainance required.

This is a classic maintainance problem, just restated in terms of the web. Maintaining parallel content either requires ongoing extra work, or it requires that you find a way of factoring your problem. With the web your issue is that the design tools that designers like to use tend to not play well with trying to factor the problem. The three answers I gave trade off differently depending on what resource you can most easily waste: HTML designer's time (on synchronization), programming time (on figuring out how to modify code to produce different HTML), or a bit of everyone's time (on setting up and maintaining a clean separation).

In reply to Re (tilly) 6: Code Critique? by tilly
in thread Code Critique? by rostiguy

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.