Thank you.
>I want some easy
>way of changing the entire site design/layout quickly without going
>through every single HTML file.
I just would like to draw your attention to a templating tool like SDF,
where you can write your stuff in simple basic markup, in palin text
files, and where the tool can generate HTML, RTF, ... from it. One
source, many targets.
I don't know how actively developed it is. At the time I looked at it,
which must be a few years ago, I found that developing the templates
wasn't that easy as I would have imagined to be possible.
Still, it's a nice concept, and it's free.
<http://www.mincom.com/mtr/sdf/>
All you need is perl, which is free, too. For Windows, which is what I
assume you use, there is, for example, ActivePerl (from
<http://www.activestate.com/Products/Download/Get.plex?id=ActivePerl> or
IndigoPerl (from <http://www.indigostar.com/indigoperl.htm>).
--
Bart.
If your content is mostly static, there really is no real compelling
reason to put it into a database. It will just cost you more overhead.
Your best bet is going to probably be some sort of combination of
tools. I would suggest using CSS (external stylesheets instead of
internal style declarations) with SSI (keeping in mind the load
impact of SSI pages). I would also strongly suggest you using Apache
as your webserver and running it on a Unix machine (or finding some
company to host it for you).
You create a couple of standard SSI files that are consistent for
everything on your site like ".header", ".footer" and ".navigation".
Then you create a standard CSS file (or files) that covers all of
the presentational aspects of your site and link it in through the
.header file.
Then you can do something like the following:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3c.org/TR/html4/loose.dtd">
<html lang="en-US">
<head>
<title> Article </title>
<!--#include virtual=".header"-->
</head>
<body>
[[ Article Body Goes Here ]]
<!--#include virtual=".navigation"-->
<!--#include virtual=".footer"-->
</body>
</html>
If you plan out your site ahead of time, you can solve a lot of your
problems before they happen. I strongly suggest that you think about
the structure of your site (and pages) separately from the presentation
of it (them). Then logically lay things out according to the structure.
fpsm
--
| Fredrich P. Maney maney at maney dot org |
| Do NOT send me HTML formatted E-mail or copies of netnews posts! |
| Address in header is a spamtrap. Use one in signature for replies. |
| Please review http://www.maney.org/fred/site/uce/ before emailing. |
I've spent the last two years of my life developing two slightly
different content management systems; they're quite good and are used
by some very large organisations. But they aren't as good as I want
them to be and I'm now trying to make up my mind whether I've got the
energy to build a new one using the lessons I've learned.
Yes, obviously, content management is a good idea; yes, it's easy to
get started with content management systems. But building a useful,
flexible, secure, reliable content management system is a *lot* of
work.
From my experience I strongly recommend using XSL-T as your template
language - it's both extremely flexible and extremely easy to use. As
to hosting, if you design your content management system to static
compile your site (one of mine does this), then you can just FTP the
static compiled site up to your public server when you've finished.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
Age equals angst multiplied by the speed of fright squared.
;; the Worlock
A free download will be available in a few days.
Darren.
"Keith D" <miste...@hotmail.com> wrote in message
news:97f29096.01120...@posting.google.com...
There stil is, and ASP or PHP can make your life so much easier without
taking on the performance hits inherent with SSI
> Your best bet is going to probably be some sort of combination of
> tools. I would suggest using CSS (external stylesheets instead of
> internal style declarations) with SSI (keeping in mind the load
> impact of SSI pages). I would also strongly suggest you using Apache
> as your webserver and running it on a Unix machine (or finding some
> company to host it for you).
>
> You create a couple of standard SSI files that are consistent for
> everything on your site like ".header", ".footer" and ".navigation".
SSI is the worst choice, especially considering that PHP or ASP is about
standard with most hosting companies.
B.P.
I use http://www.linuxwebhosting.com, they are cheap, $8 for a 20mb site
and half off each additional domain. They offer Perl, PHP and MySQL as
well as java servlets. Their reliability is moderate, but in almost 3
years I have not had any major problems with them.
PHP is relatively simple and there are dozens of free scripts to get you
started with your content management system.
But before you embark on learning any scripting language, get a good
book. The PHP Bible is a good book for PHP.
B.P.
> SSI is the worst choice, especially considering that PHP or ASP
> is about standard with most hosting companies.
For including static files I don't think SSI is going to cost much
more than PHP, if any. They're both Apache modules, not like an
external program needs to be fired up.
Of course including static files should probably been done with a
preprocessor. So I would consider PHP complete overkill for this.
The plus side to SSI is that you need not change the file extension
(use XBitHack). So if you change your mind later there's no broken
links and redirecting. I suppose .html could be set up to get
parsed by the PHP but that just seems weird:-)
--
Rob - http://rock13.com/
Web Stuff: http://rock13.com/webhelp/
> The plus side to SSI is that you need not change the file extension
> (use XBitHack).
Indeed - and with XBitHack full you get more control over how your
server advertises cacheability. (Assuming Apache, of course).
> So if you change your mind later there's no broken
> links and redirecting.
There's no architectural _need_ to include filename extensions
in URLs - it's the server's responsibility to resolve URLs into
actual filenames. And for example with Apache MultiViews there are
useful things one can do with that mechanism.
I only (usually) include filename extensions for the reason that
Nielsen sets out - "users spend most of their time on other people's
sites" and they get to expect it, so they can get confused when it's
not there. Oh, and it sets the default filename for downloads, but
that's not a major issue.
> I suppose .html could be set up to get
> parsed by the PHP but that just seems weird:-)
;-)
[f'ups narrowed. Confucious say: on-topic for *.misc implies
off-topic for *.specific and vice-versa.]
http://www.w3.org/Provider/Style/URI.html
might be worth reading (not that I necessarily agree with it...)
Jim.
--
"[Advertisers] use Macromedia's Flash to do terrible
things to your computer screen." BBC News Online
> >I only (usually) include filename extensions for the reason that
> >Nielsen sets out - "users spend most of their time on other people's
> >sites" and they get to expect it, so they can get confused when it's
> >not there.
> http://www.w3.org/Provider/Style/URI.html
>
> might be worth reading
Hi, Jim, I'm not unfamiliar with that page. It might be worth the
rest of the WWW reading it ;-)
> (not that I necessarily agree with it...)
Well, minor niggles, but by and large I think it's right.
Pragmatically, Nielsen's principle still needs to be taken into
account, though. (Shall I turn in my purist's badge now?).
Hi Rob, it's been awhuile since I have been here. Hope all is well.
Either way both files have tio be parsed. PHP is much quicker plus gives
you freedom to expand as you see fit. Plus with PHP, you can make a
reasonable attempt to screen out NN4.7 and deliver proper style sheets and
assign global values to replace/fix/add elements to recover from browser
specific bugs. On top of that, you can have PHP write out much of the
redundant HTML and shrink files down in size tremendously. Any additional
overhead would be offset by reduced file loading and delivery times.
IIRC SSI still goes thropugh the CGI interface which is generally slow and
insecure.
It would be interesting to see the performance hit by using SSI vrs PHPfor
simple static page includes
>
> Of course including static files should probably been done with a
> preprocessor. So I would consider PHP complete overkill for this.
That is what PHP is recursive acronym for "PHP: Hypertext Preprocessor"
It is easy to sometimes forget this considering the power PHP offers.
>
> The plus side to SSI is that you need not change the file extension
> (use XBitHack). So if you change your mind later there's no broken
> links and redirecting. I suppose .html could be set up to get
> parsed by the PHP but that just seems weird:-)
Yes, thsi is the most important consideration. Once you go to PHP or ASP
for that matter, you are really kinda stuck without having to do a lot of
work eredirecting links.
But in the end, PHP
Rocks :-)
B.P.
I would seriosuly consider a discussion on the benifits of authoring HTML
via PHP or SSI pretty much on topic.
B.P.
If you are running Windows, you can use PWS (which contrary to popular
misinformation) is exactly the same as IIS(Internet Inferction Server). It
is free and will handle 30 people a day wuite nicely on your machine. It
is located on the win 95/98 cd, or on the NT/2000 cd as an option pack You
can use the built in ASP, download and install PHP, perscript, or TCL, or
Python. Add in MySQL, and you have a nice little compact easy to use
development system.
I would suggest you download HTMLKit (www.chami.com) and the additional
plugins for PHP, Perl, javascriipt, etc.to use as an HTML/Scripting editor
and CuteHTML is excellent for remote editing and as a general all around
text editor.
Outside of that, there are zillions of free webhostign places like tripod,
geocities, etc...
Good luck.
B.P..
[F'up set]
> "Rob - Rock13.com":
>> B.P. <news:3C101C15...@ispelunker.com>:
> Hi Rob, it's been awhuile since I have been here. Hope all is
> well.
It's going alright.
> Either way both files have tio be parsed. PHP is much quicker
> [than SSI] plus gives you freedom to expand as you see fit.
I suppose it may be faster, can't find anything that really
compares the two. I peeked at the C source for mod_include but
don't know very much C to start with so that will have to wait for
a rainy night.
As I said, for including static files, I can't see the cost being
very different between the two (nanoseconds or so, perhaps).
> Plus with PHP, you can make a reasonable attempt to screen out
> NN4.7 and deliver proper style sheets and assign global values
> to replace/fix/add elements to recover from browser specific
> bugs.
Hm, I guess that is a use. XSSI can look at the User Agent but
doing much of that would probably make PHP look more appealing.
>> Of course including static files should probably been done
>> with a preprocessor. So I would consider PHP complete overkill
>> for this.
>
> That is what PHP is recursive acronym for "PHP: Hypertext
> Preprocessor"
Indeed, but I was meaning preprocessor as in before the httpd gets
its fingers on the file. (I probably should not be going on about
PHP without more knowledge of it, sorry. Perhaps PHP can cache the
documents after its first parse, and keep them for a long while?)
In the end simple includes (files or dates or whatever) should be
left to SSI for the simple benefit of being able to continue using
the expected .html. IMAO. The server's time is cheap[1], ours is
not, so if I can get something done in SSI more quickly than PHP
then that's a good thing:-)
[1] Ultimately, every little bit is going to count but not for the
vast majority of web sites.