I started blogging a few months ago and understood that it is a very good thing. However, I've always wanted to work with a simple blog CMS that I understand and can extend easily. I'm a person who likes creating things instead of reusing :-) so a couple of months ago I decided to write my very own Blog CMS, which I could use with a joy.

Time ran but I was stuck with a framework. GoDaddy's economy hosting was did not support PHP5 so I was limited to PHP4 only. But programming with PHP4 underdeveloped classes was a pain and took a lot of my time. And I had already heard about Zend Framework for many times but still did not have a chance to use it in a real world application. And last week I discovered that GoDaddy had created a new hosting configuration that supported PHP5. I upgraded immediately, downloaded the framework's latest version and started digging.

The first impression was a shock. I understood how much time I had wasted trying to recreate some basic things like controller, class loading, view, and database layer. I found out that Zend Framework's approaches match my notions about how the things should be done and just jumped into developing of the blog content management system (that is, of course, very big name for six pages that work together, but I would like them to grow).

The first module I started using was a controller. I wanted to create six pages:

• main blog page that displays a list of blog posts or one post;
• atom syndication page that exports the content of the blog in Atom 1.0 format;
• login page that prevents from unauthorized access to administrative section;
• posts management page with a list of posts;
• adding/editing post page;
• and, finally, the 404 page that handles the corresponding error.

I created the "_/application/controllers" folder and placed three controllers into it:

• indexAction - redirects to /Blog/Index
• noRouteAction - shows the 404 page

• indexAction - shows the blog posts or one post
• atomAction - syndicates the posts

• indexAction - shows the login form
• postsAction - shows the list of posts
• postAction - shows one post in edit mode

There are a few examples of what action is executed for a particular URL:

http://.../ - IndexController->indexAction
http://.../Blog/ - BlogController->indexAction
http://.../Blog/Atom/ - BlogController->atomAction
http://.../Admin/ - AdminController->indexAction
http://.../Admin/Posts/ - AdminController->postsAction
http://.../Admin/Post/ - AdminController->postAction
http://.../abracadabra/ - IndexController->noRouteAction

Everything ran flawlessly and I started developing the model of my application.

Model is a base of View pages and should provide them with a data that they should not reshape. And making things like this requires you to get a pencil instead of a keyboard and think carefully what these pages should display.

I wanted my blog page to be a classical two column XHTML/CSS page with a blog name and a description in the header, ads and buttons in the left narrow column and the blog posts in the right sizable column. I wanted my posts to be tagged and "Prev page", "Next page", and "Main page" navigation links below the list of posts. My ideas required a good database and I opened the documentation for Zend_DB that is a database access layer of Zend framework. I like its database object mapping approach; however I consider it useful mainly for administration purposes: inserting/updating/deleting data from the database. Selecting data generally requires much more logic in the SQL and because of this I split model of the application into two main sections:

• Object mapping to main tables using Zend_Db_Table class
  These classes contain field-to-property mapping for tables in which I need to modify data and encapsulate data modification logic. So when I need to create a new post I just call "insert" method of DbPosts class with the post's parameters and the method creates data in "posts" table and two related tables: "objects", which stores information of all CMS objects, and "tags", which folksonomizes the CMS objects.
• View-specific queries
  The data selection queries are much more complex than insert/update/delete queries and it is a good idea to encapsulate them in one class that provides only general purpose methods. The row sets that are returned by these methods are supposed to be used by the application's View without reshaping. In other words, the concept behind these methods is the same that behind the stored procedures of the database.

You can find the object mapping and queries classes in the "_/application/model" folder. I also created the small proxy class (BlogModel) that collects the information from a few row sets in one package and does final shaping of the data.

I use SQLite for storing data records of my blog because I want my application to work right after unzipping, without performing any installation-related tasks such as creating new database, granting permissions and so on.

The database design and data access classes took a most of my time--implementing View was simpler than the controller programming and in many times simpler than designing a database layer. View is just a few PHP scripts that you can find in "_/application/view" folder.

Zend Framework makes my programming easier and I like it. The framework is a young project and lacks in some important areas. I did not find classes for content syndication (I created a few classes for this) and View components, such as DataGrid form. However, it already has a lot of useful classes and with power of the controller, Zend_Db, and Zend_View your can create good applications much faster.

Personally I see a lot of areas where I can extend my blog: adding track backs with Zend_XmlRpc, gathering information from online services with Zend_Service, implement search with Zend_Search, and use Ajax controls with Zend_Json. Stay connected and, I hope, you will find a lot of interesting things to play with.

P.S. You can download the source code of the described blog CMS from my blog post Blog CMS with PHP Zend Framework and SQLite.

P.P.S. Great thanks to Kate for proofreading this article.