Re: databases: storing pages in / web front ends to
Subject: Re: databases: storing pages in / web front ends to
From: "Steve A. Olson" <email@example.com>
Date: Thu, 18 Jan 1996 13:33:49 -0500 (EST)
From firstname.lastname@example.org Thu Jan 18 13: 34:06 1996
X-Mailer: ScoMail 1.0
The db approach also gives you the ability to "author"
the pages using any client-server database package (even remotely)
to update the content without messing around with any files at all.
> | Gee, do you actually want to put regular HTML pages into a database as
> | objects, even if they just contain static text? I've been asking
> | people about this, and haven't heard much interest in it, so I'm
> | curious what you feel would be the benefits ot such an approach.
> Yes, I do. My reason for wanting to do this is that if I am providing
> a single `page' in several formats, e.g. Lynx-compatible, Mosaic,
> Mozilla, and several different languages, I don't want to have to deal
> with umpteen files. If everything is encapsulated in one place, and I
> can just say `display yourself' to this object, life suddenly becomes
> easier. My idea is to treat it much like a C++ class, and derive
> classes with more complex behaviour from a basic page object, which I
> envisage resembling a normal HTML page in appearance, but with the
> ability to add another language version to itself when requested -
> some sort of admin tool would check out the text for a language (=E0 la
> SCCS/RCS) and check it back in. The page object would also be able to
> do integrity checking, by maintaining pointers to other page objects,
> and creating links to whatever they happen to be called on the fly.
> Moving things around within the web hierarchy then becomes easier as
> well, almost as a side-effect.
Applied Information Technologies, Inc.
Steve A. Olson