http://qs321.pair.com?node_id=200539


in reply to Re: using perl for personal web page program
in thread using perl for personal web page program

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.
  • Comment on Re: Re: using perl for personal web page program

Replies are listed 'Best First'.
Re: Re: Re: using perl for personal web page program
by Django (Pilgrim) on Sep 25, 2002 at 07:18 UTC

    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.

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

Re: Re: Re: using perl for personal web page program
by George_Sherston (Vicar) on Sep 25, 2002 at 09:16 UTC
    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
Re: Re: Re: using perl for personal web page program
by Abstraction (Friar) on Sep 25, 2002 at 02:29 UTC
    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.