Revised Program Flow

Baby steps.

I've revised the program flow to clarify the process of receiving a request from a web site user and how the response will be put together. This probably isn't too exciting but feel free to check out the new version.

It's not much to look at but it should be a close representation of the final process. Allow me to touch on some of the items that I am trying to accomplish with this process.

Validate Request and Locate Resource

A feature that I feel is important to have is URL Rewriting. This means that a request for the virtual resource /en/article/buildings/ would actually map to a specific object in the CMS. Therefore, a process needs to exist to take that resource and actually find it in the database.

Along with that is localization. A request may be for a specific language and that information has to be handled as well.

Once I have an object id and the language that should be retrieved, the CMS will check if it exists. If it doesn't then I redirect to an error page. Otherwise, I take that id and language information and pull some information from the database that will be required for the next stages. In particular, the object type (aka Content Module) and the template that should be used for this object.

Process the Request

Once I have my resource, I can actually process the information. Step 1 is to see if I'm even allowed to request or submit information to this object. For example, do I have to login to a "members only" section before I can access the page? Or maybe my IP address has been banned from posting a comment to a forum.

If everything is okay then the content gets filtered. There are numerous reasons why content may need to be filtered. Maybe a users comment needs to be revised to be proper XHTML. Or maybe the data needs to be validated to ensure the user has entered the information correctly. The CMS should allow the site administrator to be able to define what those filters may be.

Build Page

Now that the request has been processed, the response needs to be generated. The first step is to get the layout template and parse it for all the specific elements that will need to be pulled from the database.

The next step is to pull out the Content Module template. A Content Module template defines how a particular module lays out the page. For example, if it's a photo gallery, that it lays everything out in 5 columns and 3 rows.

I now know all the content that needs to be pulled from the database to generate this page. On the way out, the content gets filtered. You may want to filter content on the way out for XHTML compliance. Or maybe to strip out all HTML tags for syndication purposes.

With all the pieces of the puzzle, I can now build the final page to be delivered to the user.

Moving forward

Did any good come out of refining the program flow? Absolutely. For one, I now have a more concrete view of the process. But more importantly, I've discovered that I need to add some way for a site administrator to be able to define filters.

And that's the point of doing all this before doing any coding. Can you imagine being half-way through development only to discover that this new functionality had to be implemented? Then the solution becomes more difficult to implement and shortcuts become the easiest way to get the functionality in.

That's it. Baby steps.

Now onto Database Design.

Published October 16, 2004 · Updated September 17, 2005
Short URL: https://snook.ca/s/260

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.