in reply to Server Side Includes

It might be easier to do if you put the content in a database, and pulled it from there. This would also give you the ability to make a page they could easily use to update the content, a way to track or display previous entries, etc., plus does not run into the issue of someone retrieving the page while you are rewriting the file with the content....

Just a thought. Hope that idea helps...

Replies are listed 'Best First'.
Re: Re: Server Side Includes
by lilphil (Scribe) on Jan 26, 2004 at 02:07 UTC
    atcrofts idea is probably best, but you could have a look at using a wiki if the data is less static. Wiki's are usually open for anyone to use, but most of them have authentication options. You would need to alter the templates to make sure it doesnt look like a wiki to outsiders.

    I'm using twiki at the moment, which has both authentication and easy to edit templates, however I'm thinking of moving to tikiwiki for various offtopic reasons.
[reply]
Re: Re: Server Side Includes
by Vautrin (Hermit) on Jan 26, 2004 at 17:27 UTC

    atcroft has the right idea. I had a simlar project and used databases for the following reasons:

    1. Most databases have built in security, like only allowing certain IP addresses to access only certain usernames, and allow only certain usernames to access and/or change certain portions of the site. That's a lot of stuff that would take forever to write out in Perl but is there and ready for the taking.
    2. Databases are fast and support multiple concurrenct connections. Files are slow and you can have race conditions if someone is trying to modify a file while it is being read. (Not to mention that you don't need to worry about things like file locks, etc.)
    3. Not all users are sys admins. Giving FTP access to a directory your scripts live in and telling them to upload files is asking for trouble.
    4. Regarding the last one, it's pretty easy to create a Tk or GTK based client to connect to the database and do everything transparently.
    5. Regarding the last one, if you use CSS on your site you can even allow your users to change things at will. You can also have sections formatted using class="" attributes, i.e. user inputs 5 paragraphs, perl splits the paragraphs on m/\n\n/, (remember to s/\r//sg), the CGI script you write outputs them as <p class="sectionFoo">content</p>, and it will look nice because the CSS tells the browser what to do for each class sectionFoo
    6. It's much easier to understand whats what when your directories aren't crowded by random text files.
[reply]
[d/l]
[select]
Re: Re: Server Side Includes
by gothic_mallard (Pilgrim) on Jan 26, 2004 at 17:04 UTC

    I'd agree with doing it with a database if at all possible. Most of the sites I've built in my time have been DB driven and in my experience it makes like a lot easier.

    Probably the most important thing is to not let the user touch anything directly (you don't want them in the actually DB interface or writing directly to a file just in case they end up putting something in that your output system doesn't like) - if you write a set of HTML forms to enter the content and validate it before it gets anywhere near storage you should be fine.

    In short - if you have access to a DB, then I'd always use it in preference to static include files.

[reply]

In Section Seekers of Perl Wisdom