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.
For example, here's some sample pseudo-code from a file called
form.asp:
<%
some code to process form
some more code
.
.
.
if code is successful then
Response.Redirect("form2.asp")
End If
%>
<html>
<form method="post" action="form.asp">
some form elements
some more form elements
</form>
</html>
This method is cleaner than setting form actions to different pages,
allows for a wizard-style interface, easy form validation, and allows
you to easily direct the user to incorrectly inputted form items.
Submission Step 1 - Putting it on the server
Let's assume that content is already written and is in some
text-compatible format. How do you get the file on the server? Well,
there's two ways to do that. You can either:
1) Give all your writers FTP access so they can upload the file
themselves or
2) Build a web form
There are plusses and minuses to both methods. Both methods require
special permissions: method 1 requires FTP write permissions, while
the
second method requires either the user to be logged onto the server or
HTTP write permissions. Also, with the first method, the upload
process
must be done separately from the management steps, and you'll have to
supply the management system with the exact file name later. The second
method will (or at least should) supply you with the exact file name
and can be part of the whole system.
If you decide to go the second route, you'll need either a COM object
or some strong knowledge of HTML binary form submission. Two common
COM objects used for uploading files are:
There's a great tutorial here at
15 Seconds.com
on how exactly to upload files, so I won't explain it now. If you're
a clever programmer and know the nitty-gritty of HTML form submission,
then you may be able to create an ASP script in place of the COM
object.
If you decided to make your writers submit their articles into a web
based form, then you don't need to know about those COM objects
above (but aren't you glad you read it anyway?). Instead, have your
writer type or cut-and-paste his article into a textarea element on a
web form. Then simply use the file system object (check out
4GuysFromRolla.com
for a great tutorial on the file system object) to write that file on
the server.
Okay, so the file is up. Now what?
If you followed step 2 from above, your ASP script should know the
file name. If not, you'll have to build an extra step to ask the user
for the file name. Once you get it, you'll want to store that filename
(and maybe the absolute directory the file is in) in the database, so
you don't forget it. The following code will enter the filename into
the database: (note that the SQL statement uses the table name we
created above).
<!--#include virtual="/scripts/adovbs.inc" -->
<%
set connFileName = Server.CreateObject("ADODB.Connection")
set rstFileName = Server.CreateObject("ADODB.Recordset")
connArticles.Open "dsn=my_db;DATABASE=my_db"
strSQL = "SELECT * FROM tblFiles"
rstFileName.Open strSQL, connFileName, adOpenKeySet, adLockOptimistic
rstFileName.AddNew
rstFileName.FileName = "blah.html" <--- Substitute
actual file name here
rstFileName.Update
intID = rstFileName.UID
rstFileName.Close
set rstFileName = Nothing
connFileName.Close
set rstFileName = Nothing
%>
NOTE:
adOpenKeySet and adLockOptimistic are Visual Basic
constants. They
are not readily available to the ASP environment, meaning
that if
you try to use the code above, you'll probably receive an
error on
the rstFileName.Open line. You can do one
of two
things: either use the numeric values of those constants, ie,
adOpenKeySet=1, adLockOptimistic=2, etc (but who can
remember all
those values?); or include the file ADOVBS.INC in the page.
This
file is usually located in the scripts virtual directory of
the
web server. If not, hunt around, it's there somewhere.
Now you have a means to access the file later. Before you move on
though, you'll want to know which document to use in the next step.
Since the form on this page was self-referencing, you can't call a
Request.Form in the next step to figure out the ID number
of the document you just submitted. Instead, at the end of the of
redirect URL, attach a querystring with the ID number, using intID
that
we created above:
Response.Redirect("step2.asp?ID" & intID)
Now when you need the information in the next step, just do a
Request.Querystring("ID") and you'll know which document
you were working on in the previous step.
Step 2 - Manipulation
Okay, now that the file is uploaded and you have the filename, now's
the time to do some manipulation of the file. We'll use the file
system object here to do the grunt work.
If you converted the document from a word processor's format to HTML,
chances are you'll have a bunch of extraneous HTML tags that you don't
want in there. For instance, Microsoft Word adds in a bunch of XML and
CSS tags that are used to convert the HTML document back into a Word
document, should you ever choose to do so. However, those extra
tags
add a lot of overhead to the HTML document, so if you're never
planning
on converting the document back to the Word format, you should get rid
of those extra tags. This can be done with a bunch of replaces.
Const fsoForReading = 1
Dim objFSO
Set objFSO = Server.CreateObject("Scripting.FileSystemObject") <-- create the filesystem object
Set objTextStream = objFSO.OpenTextFile("C:\SomeFile.html", fsoForReading)
<-- open the uploaded file
txtFileContents = objTextStream.ReadAll
objTextStream.Close <-- close the file
If instr(1, txtFileContents, "<xml>", vbTextCompare) then <-- if <xml> is found in the text, remove it
txtFileContents = Replace(txtFileContents, "<xml>", "", 1, -1,
vbTextCompare)
End If
. <-- remove any other tags that we don't want
.
.
Now write the changes we just made
Const fsoForWriting = 2
Set objTextStream = objFSO.OpenTextFile("C:\SomeFile.html", fsoForWriting)
<-- open the uploaded file
objTextStream.Write(txtFileContents)
objTextStream.Close <-- close the file
set objFSO = Nothing
Note that it may take a lot of these loops and fine tuning to get
rid of all the junk HTML in the files. Though this step is fairly
easy,
it takes a while to get it right. You can also perform any other file
manipulation here, for instance, if you need to change the filename,
do a global replace, add in a style sheet, etc.
NOTE:
If you use the file system object (FSO) to change the
filename,
make sure that you also update the filename field in
the database.
Otherwise you'll have a database entry that points no
where, and
a file that doesn't belong to anything.
If you'd like to split the file into multiple pages, you could do that
here too. Though I won't go into detail, I will list a few guidelines
on how to do so:
1. Create a 'pages table,' tblPages. A table that contains information
about the pages in the document. This table would contain data such
as:
Document ID, which would tell you which document in tblFiles this page
belongs to; PageTitle, a title for the individual page, ie Page
2; and
PageNumber, so you can see the order of the pages.
2. Add a field in tblFiles called NumberOfPages and increment that
number everytime you add another page. This way, you'll know
how many
pages are in every document without having to see how many actual
files
there are.
3. Name the new files something based off of the original file. For
instance, if the original document was test.html, name pages 2 and 3,
test2.html and test3.html
4. Parse the file for a logical separator, ie a paragraph break
<p> You could then split the page according to the number of
paragraphs, or allow the user to select which paragraph to place the
page break in. If you do the latter, you'll have to mark each spot the
user selected somehow. A good way to do this would be to use a form
with numbered checkboxes for each paragraph; ie if the user selects
checkbox 2, there should be a page break at paragraph 2. For each page
break, write the contents in a new file. This is the hardest step.
Here
is some logic and pseudo-code on how to do so:
dim CursorFirst, CursorLast
strNextText = file contents
for each paragraph in strNextText
Set CursorFirst to beginning of paragraph (ie at position of <p>)
If there is more than one paragraph in strNextText then
If this paragraph is not marked with a page break, then
Put all the text to the next paragraph in variable strText
Point CursorLast to CursorFirst
Else
Update tblFiles and tblPages with new page info
Write new file with strText
Clear strText
Put all the text to the next paragraph in variable strText
Put all the text after current paragraph in variable strNextText
Point CursorLast to first <p> in strNextText
End if
Else if only one paragraph then
Write strText to a file
End If
You'll probably want to put this functionality on a separate page.
This should get you started on splitting the original document into
multiple pages.
NOTE:
If you split the original document in pieces, be sure to
keep track
of those pieces as well. They should each receive an entry in
tblPages. If you move/rename/delete one, make sure you do
the same
with all the others.
Step 3 - Layout
By now you should have one or more pages with properly formatted HTML
(with all extraneous tags removed). All pages should have an entry in
tblPages, with a many-to-one relationship to tblFiles (ie there
will be
many entries in tblPages that will correspond to one entry in
tblFiles).
Now we must apply the format and layout of the existing site to the
new
content.
Choose or create a template that will be the basis of the new content.
Separate out the content that will remain static (things that won't
change from article to article) and the content that will change every
time.
Read here for a good short tutorial on templates. You can either
store the static portions in a database, or in a file. Just make sure
you know where the dynamic content goes - the title goes in the title
section, the content goes in the body section, etc.
Now to extract out the portion of the new content that you need, after
all, you don't want another set of <HTML> and <HEAD> tags,
since that part should already be in the static template. You can use
the following function to extract the necessary HTML from the document:
Function GetHTML(strContent, strStartTag, strEndTag)
' This procedure returns the portion of the HTML in strContent
' beginning with the HTML tag in the strStartTag variable and
' ending with the HTML tag in the strEndTag variable, not including the
' start and end HTML tags
' First get all of the HTML in the document.
strText = strContent
intStart = instr(1, strText, left(strStartTag,len(strStartTag)-1),
vbtextcompare)
if intStart <> 0 then
intStart = instr(intStart+1, strText, right(strStartTag,1),
vbtextcompare)
intEnd = InStr(intStart, strText, strEndTag, vbtextcompare)
GetHTML = Mid(strText, intStart + 1, intEnd - intStart - 1)
else
GetHTML = " "
end if
End Function
For instance, you'll want to put the title of the HTML document into
the database, so you'd simply make a call to this function:
temp = GetHTML(strContent, <title>, </title>)
and store the value of temp in the database. Then, you can insert the
proper portions of HTML into the template where it belongs, write the
file, and voila, you have your generated HTML page.
What about multiple pages?
If you have multiple pages in your document, you can do this for each
page. Since you stored the number of pages in each document in
tblFiles,
you can just loop through the appropriate number and write each file
this way. Be sure to add in links on each page to the others, so users
can find their way around. For an example of what the finished
multi-page product looks like, check out any article on
Enfused.com, like
this one for example.
Another feature you could add would be an email notifier - whenever a
new article gets submitted (ie whenever someone completes the
submission process) send out an email to the editor in charge. Saves a
lot of time going back and forth. Go
here
for a short tutorial on using CDO to send such emai
l notices.
You could also use the FSO to move, rename, and delete files. For
instance, the writers would upload all their documents into one
directory, and then once the file is properly formatted, you could
push
the finished files to the appropriate directories, ie in a reviews
directory, and rename it to something more appropriate.
What about images?
Occassionally a writer may include an image with the article. Using
the
system as it is now, however, will not upload the images along with
the
document. You have to do these separately. This is a simple
matter.
The first step should be to build an image tables, tblImages. This
table should store the following info:
tblImages
IID
Unique ID to keep track of records
Autonumber
Filename
The filename of the image
Text
DocumentID
The document in tblFiles that this image belongs to
Number
Fixed
Checks to see if correct image has been uploaded
Boolean (Yes/No)
While these are the only required fields, you may also store the size
information, as well as the page numbers that each image belongs to.
The upload process is simple. You'll have to go through the text of
the
document and find any images, ie, search for
<img src="blah"> For every one of these you find, you
should
add an entry into tblImages. Then build a dynamic form - for each
image
entry in tblImages, add another upload button as you did in step 1.
Then when an image is uploaded, flip the boolean field Fixed to true.
If Fixed is true, then don't display the upload form for that image.
<%
Set Conn = Server.CreateObject("ADODB.connection")
Set rst = Server.CreateObject("ADODB.Recordset")
Conn.Open "dsn=my_db;DATABASE=my_db"
strSQL = "SELECT * from tblImages WHERE Fixed = False AND DocumentID = " & ID
rst.Open strSQL, Conn
if not rst.eof then
do until rst.eof
%>
<form method="post" action="images.asp?ID=<% = ID %>"
ENCTYPE="multipart/form-data">
<% = rst("FileName") %>
<input type="file" name="File">
<input type="Submit" value=" Upload " name="Submit">
</form>
<% rst.movenext
loop
<% end if %>
For example, if we detect three images in the document, you'll first
display three upload forms. When the user uploads the first image,
check the Fixed boolean entry, and add the name of the image file to
the database. The form will display again, but with only two upload
forms this time. Wash. Rinse. Repeat.
Of course, this will do you no good if the image source in the HTML
doesn't match the filename, so you'll have to go through the file one
more time and change/verify the sources.
NOTE:
When you upload images, note that the image name in the
HTML source
might not match the actual image filename. For example, if you
insert an image called test1.gif into an MS Word Document and
export it to HTML, Word sometimes automatically changes the
HTML
source to read image001.gif instead of test1.gif.
Make sure that
you put the proper name into the database, and update the HTML
source to link to the correct image.
Administration
"Great," you say. "So now my writers can publish their own content.
What happened to the proofreading and editing you promised me?"
Fear not, this is the best part. We want to build a system that allows
the editors (most likely you) to proof, publish, delete, and otherwise
play with the article that was just submitted by the writer. Since all
the important info is stored in the database, this part will be a snap.
First, build an adminstrator's form. Using a for loop, loop through
all
the documents in the database that are not marked 'Published' and list
them in an HTML Select element. For each option, store a unique
variable that identifies that particular article, such as the UID:
<%
Set connArticles = Server.CreateObject("ADODB.connection")
Set rstArticles = Server.CreateObject("ADODB.Recordset")
connArticles.Open "dsn=my_db;DATABASE=my_db"
strSQL = "SELECT * FROM tblContent WHERE NOT Published = True"
rstArticles.Open strSQL, ConnArticles, adOpenKeyset, adLockOptimistic
if not rstArticles.EOF then
%>
<select name="DocTitle" size="10">
<% do until rstArticles.EOF %>
<option value="<% = rstArticles("UID") %>"><% =
rstArticles("Title") %>lt;/option>
<% rstArticles.movenext
loop
%>
</select>
<% end if
rstArticles.Close
set rstArticles = nothing
set connArticles = nothing
%>
<input type="submit" value=" Edit Title " name="Submit">
<input type="submit" value=" Publish " name="Submit">
<input type="submit" value=" Delete Article " name="Submit">
When the form is submitted, simply check the value of the submit input
by using a Request.Form("Submit"). If the value is
'Edit Title', then redirect to a page that allows the user to change
the title of the article in the database. The 'Publish' option would
change the Published field in the database to true, and the
'Delete Article' option deletes the article from the database, and
uses
the file system object to delete the actual file. Since you know the
path/filename of the article, by providing a link to it on the
same page, the editor can also proofread it or save a local copy on
his/her hard drive. If you'd like to edit the content online, simply
use the file system object to extract the content and place it in an
HTML textarea. Make your changes in the textarea, and use the FSO to
write the changes to the file when you're done.
A few notes
Before you go off and create your own content systems and come running
to me when they don't work, let me mention a few things here.
One of the biggest concerns is security and user permissions. On one
hand, you'd like to give writers enough permissions to do everything
they need to do without having to bother you, but on the other hand,
you don't want to give out too many permissions for fear of
security
risks. One way would be to put all this good stuff in a protected
directory, that only authenticated users can access
(
go here for a tutorial on how to set up protected folders).
This
makes sure the public can't find your system and start
bombarding you
with junky articles and such. You might also want to deny your
writers access to the editor functions we spoke about in the previous
page.
So the system works, but when you go and view the page, none of the
images appear. What now? Well, there could be a few causes here. Did
you verify the image sources in the HTML? And are the images in the
correct directories? Remember if you used the FSO to move your files,
you have to move, or at least rereference, your images too. Another
sneaky culprit is directory permissions. Make sure that all files
placed in the directories are viewable by internet users. In NT, this
means making sure the files inherit the permissions of the
directory.
Another thing to keep in mind is stray files. Every time you go
through
the submission process, you'll probably end up with a new set of
files.
Many times, for whatever reason, these files won't get published,
possibly because they were test or duplicate files, deadlines changed,
etc. By keeping track of things in the database, you are able to see
what files are there. Make sure that if you delete something from the
database, you delete the actual file as well. Otherwise you'll end up
with a bunch of files that you didn't know existed, and you'll eat up
valuable hard drive space on your server.
Naming files. Have you ever been to a larger web site, such as
CNet.com or
Enfused.com, and seen a filename
in the address bar such as 10,31,95_0_0_1,2.html? Chances are, these
pages are created using a content management system. The system names
each page something unique that will never be confused with something
else. Sometimes you may be able to get away using a simple name, such
as review.html or intro.html. However, when you have many different
articles to publish, you may find that you will run into naming
problems. It may be a good idea to name your articles something
unique,
possibly something that depends on the current date/time. This will
ensure your articles will never be overwritten if another
article with
the same name pops up.
Conclusion
Conclusion
It's also easy to rotate content this way. If you have a list of
articles somewhere on your site (possibly the front page) you can just
make a call to the database instead of having to rewrite HTML every
time you add an article. Just list the five newest articles, and if
you add content regularly, this list will constantly be updated.
Another feature that I've omitted here for time's sake is the
expiration of articles. Suppose you have a news article that applies
only to this week - next week no one will ever read the article, so
you want to get rid of it. By adding a simple step and another field
in your database, you can add an expiration date. Then write a
simple
script that can be scheduled (go
here for a tutorial on scheduling scripts) to check
the database periodically and see if an article's expiration date is
passed. If it is, you can use the FSO to delete the article, delete
the database entry, or simply uncheck the Published field. Very handy.
The moral of the story is, who needs to pay big bucks for great
content
management? With a few tweaks and modifications, this system we've
described will work very well and handle most anything you could throw
at it. Using the basics from this system, you could create a larger
workflow management system, where you manage more than just articles,
and track them from all over a network.
Proposion N2N connects Microsoft .NET applications to Lotus Notes and Lotus Domino databases. This ADO.NET managed data provider allows you to perform blindingly fast queries and updates of Notes data from ASP.NET pages, .NET web services, Windows, or Mobile applications. An innovative SQL-like query language leverages the unique features of Notes and makes collaborative software accessible to relational database programmers.
Unlike text-based file formats image files aren't made up of words, which makes searching for an image file by keyword difficult. Instead of being able to simply open the file to see what it contains, we're stuck looking at the text around it and other metadata to determine the image's meaning. In this article, Ziran Sun shows you how to build a simple database-based image keyword system that allows you to associate keywords with images and use these keywords to make finding images easier. [Read This Article][Top]
In the second part of of his article on using MySQL with ASP.NET, Ziran Sun covers how to add a new MySQL user to the database server, assign the user the appropriate permissions, connect to the database, and build a simple ASP.NET page to perform a query. [Read This Article][Top]
Back in the days of classic ASP, if you were building a database-driven
web site, your choice was either to invest a lot of money to get a copy of Microsoft SQL Server
(or some other enterprise-ready database) or invest a lot of time finding a way to deal with the
performance and scalability limitations of Microsoft Access. Luckily these days there's
another viable alternative: MySQL. [Read This Article][Top]
Moving or copying a SQL Server database from one machine to another requires a lot of preparation in order to ensure a smooth transfer. In this article, Dina Fleet Berry examines the different methods and highlights the different issues associated with each of them. [Read This Article][Top]
There are many times when using SQL Server 2000 Query Analyzer to debug SQL statements is a better choice than debugging in Visual Studio .NET. In this article, Dina Fleet Berry explains why and walks you through the debugging process step-by step. [Read This Article][Top]
As a follow up to his article on retrieving objects from SQL Server using SQLXML and serialization, Gianluca Nuzzo discusses saving objects back to SQL Server using a schema definition file and updategrams. [Read This Article][Top]
One area that stands out when comparing ADO.NET 1.x to ADO.NET 2.0 is transaction processing. Bill Ryan shows just how easy transaction processing has become with the TransactionScope object in ADO.NET 2.0. [Read This Article][Top]
Developers often use brute force coding to marshal data between the GUI and application objects. In this article, Luther Stanton explains how to use .NET's out-of-the box data-binding functionality to make this job much easier. [Read This Article][Top]
Learn how to create a console application to queue a message in Microsoft Message Queuing (MSMQ) and then use an extended stored procedure to call the console application from a SQL Server trigger. [Read This Article][Top]
Connection pooling increases the performance of Web applications by reusing active database connections instead of creating a new connection with every request. This article shows how to monitor the connection pool, diagnose a potential problem, and apply the appropriate fix. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
