Adding pages "on the fly" with a CMS system

Question

Hi,

I am in the process of building a website content management system for one of my clients. It's a highly customized system, so I cannot use any "of the shelve" solution.

I need to allow my client to add pages to the website on the fly. I have two options here: (1) Create a database driven page in the format of www.mycompany.com/page.aspx?catID=5&pageID=3 (query the database with the category and page ID's, grab the data and show it on the page) - or - (2) Allow the management system to create static pages, something like www.mycompany.com/company/aboutus.aspx and www.mycompany.com/company/company_history.aspx , etc.

I believe that, while the former is much easier to implement, the latter is a better both for the user AND for Google.

My questions are (finally): (1) Would you agree that the latter is a better solution, and (2) What is the best way to implement such a solution? Should I create and update each file using the FileSystem (i.e. - the site's management system requires the user to supply a page/file name, page title and content, and creates the page on the fly based on these parameters)? Is there a better way?

Thank you!

Answer 1

It's entirely possible to have database driven pages with nice URLs. StackOverflow itself is a great example - this question's URL is http://stackoverflow.com/questions/1119274/adding-pages-on-the-fly-with-a-cms-system, but the page is built from the database, not static HTML.

Answer 2

I would use the first solution, but mask the addresses using a custom request handler. Basically, give each of your pages a unique string ID (such as about-us) and then, with your request handler that takes all requests, find this particular page in the database and render it.

See this article for some additional info (found it when googling for custom http handlers in ASP.NET.) In that article, it has the following handler added:

 <add verb="*" path="*.piechart" type="PieChartHandler"/>

You would probably want to catch all paths (*), excluding certain media paths used for CSS, images and JavaScript.

More resources:

• Custom HTTP Handler
• HttpHandler in ASP.Net

Answer 3

I'd stay clear of static pages if I where you. Dynamic Data, MVC and some good planning should take you a long way!

What you need to do is to create some or many templates that each view/controller in mvc can use. Let whoever is responsible for the content handle it through dynamic data entities.

Answer 4

I would use the first idea, but work out a better URL scheme. If the system doesn't provide nice URLs (without ?), you'll have trouble getting the search engines to parse the whole site. Also using numbers instead of words make it hard on users to pass around URLs.

If you start to have performance problems you could add caching that would generate static pages from time to time. I would avoid doing that until you have to; caching can cause many headaches along the way to getting it right.

Answer 5

Although the existing advice is more-or-less sound, the commentators have failed to consider one factor which, admittedly, you haven't given much detail on. Are these pages that they'll edit once they're built, or a they one-shot creations? If the latter, your plan of generating static pages isn't quite so bad as they suggest. Why bother even having to think about database schemas and caching, when you can just serve flat content.

It will probably make for pretty lifeless, end-of-the-road pages, but if that's what you want ...