spartacus9 has asked for the wisdom of the Perl Monks concerning the following question:
the association i work for has tasked us with developing a program that will allow our members (about 100,000 physicians) to create their own small web sites to promote their practice. we have a large web site with many services geared toward our members, but there has been a heavy focus over the last year on a new system allowing our physicians to put their practice on the web. their vision is a system that will be similar in nature to that offered by webMD and yourMD.com. Aside from the obvious hardware issues that will need to be addressed in order to offer a service of this volume, there are some major software decisions that need to be made here.
Our strongest language amongst the four programmers, myself included, is Perl, and that is most likely the language we will use in development, probably using MySQL to store the data and using modules like HTML::Template to render the output.
Before we start developing our own home-grown system, I would like to solicit the advice of fellow monks who may have developed similar systems or know of existing open source software that can be customized to meet our needs. This program will have to be extremely flexible, allowing the inclusion of photos, office schedules, lists of office staff, etc. Any suggestions or experience to offer? I would rather not re-invent the wheel if there is a flexible product or solution out there.
|
Re: using perl for personal web page program
by BUU (Prior) on Sep 24, 2002 at 05:02 UTC
|
Just off the cuff, and without knowing more, you could look at everything engine (see bottom of page) and slashcode, both of those are supposed to be faily easy to twist into horrid things. | [reply] |
Re: using perl for personal web page program
by Django (Pilgrim) on Sep 24, 2002 at 10:50 UTC
|
You may find some useful suggestions in this thread.
~Django
"Why don't we ever challenge the spherical earth theory?"
| [reply] |
Re: using perl for personal web page program
by hawtin (Prior) on Sep 24, 2002 at 22:07 UTC
|
I created a program that generates static web pages to
navigate round a directory full of photographs. From my
experience I would say:
- Develop it in Perl (of course)
- Have the script interpret a simpler language
that "real people" can use (my current best thought
is something BASIC like)
- Have different "levels" of customisation for
different needs and different levels of your users
- Write "How to customise your web page" documentation
before you write your code (it will be wrong but
the exercise of writing it will help clarify how
it should work)
I would also suggest that you steal ideas from my software but I
haven't got round to releasing it yet.
Update: I have now, it is
here
| [reply] |
Re: using perl for personal web page program
by George_Sherston (Vicar) on Sep 24, 2002 at 19:05 UTC
|
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 | [reply] |
|
|
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.
| [reply] |
|
|
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?"
| [reply] |
|
|
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
| [reply] |
|
|
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.
| [reply] |