can I build my own content management system?
Keith D
decided to drop that idea after looking at all the problems with it
(like text being cut off, only 1,2 or 3 colum layouts). What I'm
trying to do is set up a small personal web page for my hobbies. Since
I will be writtin a lot of tutorials and articles, I want some easy
way of changing the entire site design/layout quickly without going
through every single HTML file. I figured it would be pretty easy to
make a nice HTML template that would be compatable with most of my
articles, and then drop text into it. What I've found so far is SSI,
but that would require many small text files for each article. And if
I wanted to rearrange how photos are integrated with the text (like in
a cell next to each paragraph, or inline), that would not be possible
with just a SSI. It makes sense to me to use a database to hold the
contents of each article, so each paragraph/picture can have it's own
field. But what database formats are designed to hold lots of text and
photos. I have microsoft Access, but it has a limit of 5,000 words and
even then it seems like it's built more for address/contact type
information. I would like to find a free one too, since my site isn't
going to be making any money. And it needs to be able to be integrated
with some kind of server scripting language. Unfortunatly, I also
can't host the site on my own computer at home, we only have a 56K,
and my parents wouldn't be too happy to have my computer online all
day and night.
Thank you.
Bart Lateur
>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.
bit-b...@maney.org
: I was thinking about using a stylesheet to define my page layouts, but
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. |
Simon Brooke
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
Darren Collins
http://www.fogcreek.com/CityDesk/index.html
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...
B.P.
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.
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.
Rob - Rock13.com
> 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/
Alan J. Flavell
> 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.]
Jim Ley
<fla...@mail.cern.ch> wrote:
>
>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 (not that I necessarily agree with it...)
Jim.
--
"[Advertisers] use Macromedia's Flash to do terrible
things to your computer screen." BBC News Online
Alan J. Flavell
> >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?).
Keith D
don't need a database since my content won't be changed often. I have
this weekend to come up with some ideas. What I think I'll do is come
up with a standard HTML layout I like and that could be
"standardized", since the site is due monday. (it's for a school
project) Just to get something done for the teacher (he's the WYSIWYG)
type, so even just a handcoded simple HTML page will get me an A. Then
I'll work on figuring out a good PHP or XSL solution wiht headers and
everything. What I did think of is using a small database just so I
could easily change the URLs of external links when they change. I
guess I would insert PHP into my page to go into the database and get
the field for whatever. First I have to find a server for it that's
free. Could I use my 233Mhz 96meg RAM laptop as a server? I only get
about 30 people a day.
B.P.
"Rob - Rock13.com" <rob...@excite.com> wrote in message
news:Xns916FEB23F...@64.8.1.227...
> B.P. <news:3C101C15...@ispelunker.com>:
>
> > 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.
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.
B.P.
"Alan J. Flavell" <fla...@mail.cern.ch> wrote in message
news:Pine.LNX.4.30.01120...@lxplus023.cern.ch...
>
> [f'ups narrowed. Confucious say: on-topic for *.misc implies
> off-topic for *.specific and vice-versa.]
I would seriosuly consider a discussion on the benifits of authoring HTML
via PHP or SSI pretty much on topic.
B.P.
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..
Rob - Rock13.com
<news:v2eQ7.10851$714.1...@newsread1.prod.itd.earthlink.net>:
[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.