in reply to using perl for personal web page program

probably using MySQL to store the data and using modules like HTML::Template to render the output

I'd certainly agree with the second half of this. But do you really want to use a db to store data? Presumably these pages are not going to be super-dynamic; at most they'll change by the week; so wouldn't you be better off (from the point of view of speed in serving them up) storing your pages as pages? And that cuts out a layer of design, too AFAICS. Just a thought.

My other thought is, think through the intellectual property rights in case this is a thing you and your buddies could take private later on ;)

George Sherston
  • Comment on Re: using perl for personal web page program

Replies are listed 'Best First'.
Re: Re: using perl for personal web page program
by spartacus9 (Beadle) on Sep 25, 2002 at 02:16 UTC
    I have gone back and forth with the question of database or static page generation. This project is actually a re-write of a bastardized web page generator that we developed some years ago. That version did create static files which, I agree, served the browser much more quickly. However, it was much more difficult to perform maintenance on all of these sites at once. for instance, we offered, as part of the web page they create, the ability to include a built-in drug database -- a product we leased from a vendor. We terminated our agreement w/ the vendor a year later purchased a new product instead. Changing the HTML on 5,000 personal web pages to delete the old code and insert new code for the new drug database system was NOT FUN. w/ a database this would be much more simple.

    Regarding the intellectual property rights, I would love to think I could "take it with me" if and when I leave this company, but I am not well-informed as I should be in the area of intellectual property rights. One of my programmers has a J.D. i should probably be asking him these questions.

    Thanks for the insight.

      Maybe you should think about switching to XML/XSLT. Using XML with a simple DTD instead of HTML documents has the following advantages:

      • You're still able to use a document oriented approach instead of a database
      • Most maintenance issues can be done centrally with the XSLT stylesheets. Even if you have to do some substitutions in the pages themselves, this will be much easier with XML than with HTML source code.
      • Your users could compose their pages easily and absolutely valid with an XML editor like epcEdit or XMLspy.
      • The pages could easily be published for different media - HTML print version, PDF, plain text etc.
      The disadvantage would probably be that you have to learn some XML/XSLT basics before you start, but you'll be glad to have that knowledge in the future.

      "Why don't we ever challenge the spherical earth theory?"

      Changing the HTML on 5,000 personal web pages to delete the old code and insert new code for the new drug database system was NOT FUN

      ... I can imagine! BUT - presumably the difficulty arose because these pages were not in a standardised format. The advantage of a DB is that you have a clear way to impose the discipline of having standard elements in the page (by putting each element in DB column). Obviously you can't impose that discipline if you're going to let everyone hand-edit their pages. But if you have a dedicated interface they use to edit their pages, you can use THAT to impose the discipline, whether the data's stored in DB or in static pages. With generous uses of HTML commenting, the bits that change can be easily pulled out and operated on.

      One other thought, probably one you've already had, but the answer to the question "what rules?" is quite certainly, IMHO, "CSS". This opens up the possibility of total customisation of the appearance of individual sites, but keeping to a highly standardised template for each page. (It also opens up the possibility of shaving your head, climbing a tower with a high velocity rifle, and shooting anyone who uses NS4 - but you can just have a browser-sniffer and a standard alternative format for the unwashed.)

      George Sherston
      It sounds like you'll want to use a mix of both dynamic and static pages. For data provided by your users, server it up static and for data that is going to be global, or possibly global to all the users server it up dynamically. A compromise between speed and maintainability.