Thanks to everyone who contributed. I will use the TAG, or 'pattern',
approach and use a Java application to 'compile' the HTML pages with the
TAGs. Given the lack of dynamics of the site, creating (compiling)
static pages is appropriate.
Using the Java app allows me to eventually create a servlet so that
customers can order the site, input changes to the standard values
(replacement within the TAGs), generate the site, and have the site
JARed and mailed to them.
Again, thanks for the help.
Tim Gallagher
-----Original Message-----
From: Carver,F,NAIDP,CARVERFK M [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 04, 1999 3:40 AM
To: [EMAIL PROTECTED]
Subject: Re: Template programming
On Wednesday, March 03, 1999 11:37 PM, Costin Manolache
[SMTP:[EMAIL PROTECTED]] wrote:
> Timothy Gallagher wrote:
>
> > Well, some very good suggestions, but let me throw something else
out
> > that was discussed internally here. The intent, as mentioned by
some of
> > the replies, is to keep the Java people doing java and the HTML
people
> > doing HTML.
> >
> > Another technique mentioned by a colleque of mine is to use
JavaScript
> > in all the pages with the src attribute:
> >
> > <script language="JavaScript1.1" src="datafile.js">
> >
> > Then, generate a separate 'datafile.js' for deployment to another
> > server.
> > Body of the HTML files would use Javascript to present specifics
based
> > on
> > the data in the datafile.js.
> >
> > My first problem beyond the 'is this practical?' one, is whether or
not
> > I want to limit the users to 4.0 browsers.
>
> You can also use server side includes. Or even better - a simple Perl
script.
>
> Not everything must be in Java.
I agree with this, but I want to make sure that the full import is
understood. I am a strong believer that the appropraiet tools hould
be used for the problem. In your case it doesn't look as if you really
need *any* dynamic features at all, just a static web site
which is configured once for each new machine.
I suggest using a "source code and compiler" metaphor: Build your
web site as a completely static site, configured for one machine, then
go through and replace each bit which you are likely to change with some
unique recognisable pattern. Set up a mapping (database, properties
file,
directory full of files etc) between th eunique pattern and its
contents,
then
produce a simple script which goes through the web site and substitutes
the value for the appropriate pattern. When you move the site to a new
machine, just move the "source code" with the patterns, and the
substitution
tool, then edit the data associated with the patterns and regenerate
the
site.
The key thing to remember is that (as far as I can tell) you only want
to
configure this web site for a new machine *once*, when you install it,
not
*every tiime a request comes in*.
To restate the above quote "Not every configurable web site shoule be
dynamic". I did this a while ago, and I wrote the site-processor tool
in
Java, but you can use whatever you like - perl, awk, VB, Java, C, C++,
sed ...
Frank.
--
Frank Carver
[ Personal: [EMAIL PROTECTED] http://www.io.com/~efficacy ]
[ At Work: [EMAIL PROTECTED] tel +44 (0)1473 227371 ]
________________________________________________________________________
___
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
