So what is content management and how will it help you? When you start to develop content on a site, unless you want to be bogged down forever with HTML trivialities or resource sharing, you want to make it as painless and easy as possible. You need a system that will eliminate the grunt work and let you focus on actual content. You need a system that will allow writers to easily submit articles, one that will let you proof and publish the articles, all without having to write a bunch of HTML. Enter automated content management.
Imagine a simple news site that two different writers update twice a day. Without any content management system, the writers would have to download the source code for the current page, add their news, re-upload the page, and then let the other writer know the page is updated so they won't overwrite the changes. For a larger site, such as Enfused.com or WDVL where news is updated at all hours of the day, and longer content is added on a semi-regular basis, this system will not work.
So what are the parts to a good content management system?
Allow writers to easily submit content
Make sure a record is made of that submission
Allow editors to easily proof, publish content
Make sure content layout fits with current design
You want to be able to do all this without having to mess with any HTML, and as easily as possible. There are definitely packages out there already that allow you to do such functions, and much more, such as Vignette's Storyserver. But this nifty little app can cost you in upwards of several hundred thousand dollars. That's five zeroes we're talking about. We'll show you how to build the poor man's system here.
Ready to dive in? Let's find out how we'll let the
writers submit their content.
Submission System
There are two ways to go for the submission system. You can either let
the writer write in his/her own choice of editors, or you can force
them to use a web based form (with a textarea element) to submit their
content. Naturally, the first option would be a more robust choice
(not to mention friendlier for your writers), but more difficult than
the latter choice. Either way, you'll want to store this content
somewhere, which usually means putting it in a file that resides on
the server.
NOTE:
You may choose to store the content in a database instead of a
file. While this will allow you to keep track of and perform
database functions on the content more easily, if
your content
is long and/or you have a lot of content, your database can
balloon to extraordinary proportions. Not to mention that the
articles will have to be generated dynamically when a visitor
tries to view them, which adds more overhead to the server. We
will use text files for simplicity's sake in this article.
Should I let the writers choose?
We'll talk briefly about the first method of submission, that is, letting the writer choose his own medium. While this does seem like
the best route to take, there are a few compatibility issues. Firstly,
chances are that your all writers may use different word processors,
and no one will be able to read another person's document. So unless
you want to go out and buy licenses for all of the different editors
people use, you'll have to coordinate compatible versions. The next
issue is obvious - for people to be able to read articles online
(ie web site visitors), the articles need to be in plain text format;
Word Perfect, Lotus, MS Word, etc formats won't work. So you'll have
to convert the documents into plain text.
Unless you know the binary file format of the document and some heavy
programming, or a copy of the application is installed on the
server, you'll most likely not be able to get the actual text and/or
images out of the document. One solution is to require your
writers to
convert the documents into something you can manipulate first. Many
popular word processors these days allow you to 'export as html' or
'save as web page.' This would be ideal, since such pages are straight
text files and can easily be manipulated. Or, you could simply have
them write HTML or text files and submit those.
If, however, none of the above options are feasible, you'll have to
resort to the second method, which is to make the writers submit the
content through a web-based form.
The Back End
Before we actually start building the submission system, we'll want to
create the database backend. The tables we'll create will store
important information about the content. Here's a sample database
structure for the submission system we're creating:
tblFiles
UID
Unique ID to keep track of
records
Autonumber
Filename
The filename of the document
Text
Author
The name of the author
Text
Title
The title of the document. (Note: This is not
the same as the filename.)
Text
Date
The date of the publishing/writing
Date/Time
Published
Is this document published (ie viewable to
the general public?)
Boolean (Yes/No)
You can obviously expand this with whatever you'd like, but this is
a good framework to start us off.
Functionality
We will use a wizard type interface here - that is, the user selects
some options, hits the next button, selects some more options, hits
next again, etc. This will make things much easier to follow for the
user, and much easier to debug for the developer. How do you design
a wizard? Simply follow these easy to munch on steps:
Each step that we discuss below can be on a single
page.
Any forms on those pages (and there will be a lot)
will point to the same page (action will be set to the same page the form is
on).
Put the script that processes the form somewhere on
that page, preferrably at the top.
After the script is through, and if it is successful, redirect the
user to the next step.
Events
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
