Implementing a blog with the APF

1. Introduction

One of the most popular implementation examples on the web is a Blog. Usually, the blog described in those tutorials is kept very easy, to show how easy it is to implement a Blog with the product presented there. In fact, a Blog is nothing easy, but a complex tool, that can handle several use cases and many data.

Nevertheless, it is hard to find good tutorial topics, so the APF page now features a Blog tutorial, too. :)

2. Preparation

Let us at first have a look at the requirements of a blog. Usually a Blog has four different data objects, that must be handled: posts, categories, tags and comments. As an extended feature, a navigation can be added for structuring the Blog page. For security reasons, the blog should have a user management.

As you can see by the last few lines, Blogs are nothing that can be implemented within a 5 minute tutorial. Due to this fact, the tutorial is splitted into several parts: a quickstart, that describes the basics of the Blog and further chapters, that teach you how to implement navigation and user management.

3. Requirements

3.1. Use cases

Too keep thing simple - as we know, in reality they are not ;) - this part of the tutorial is restricted to the following use cases:

Blog use case model

3.2. Data model

To represent these use cases, the data model should look like this:

Simple Blog data model

The Post object is the central object of the data model. It composes Comments and has associations to the Category and Tag objects. The relations have been choosen like this, because a Comment object cannot exist without a Post. Instead, a Tag or Category can. The object and relation names are used later on, so keep them in mind.

4. Implementation

As you may have read in other APF tutorials sometimes it is good to start with te data layer implementation and in other cases it is comfortable to first create the presentation layer. In case of the blog, let's start with the data layer.

Please note, that the Adventure PHP Framework does not feature a build tool, that generates the skeletons for you. We consciously abstain from that, because we think that this is too intransparent!

4.1. Data layer

Due to the demand, that the data layer implementation should be kept simple, the Generic o/r mapper is used. This module provides a reusable data laser component, that can handle all data models defined by some configuration files.

As described in the object definition chapter, each object must be defined within one configuration section. The following code box shows the configuration of the data model depicted above:
APF configuration
[Post] Title = "VARCHAR(100)" Teaser = "VARCHAR(200)" Content = "TEXT" [Category] Name = "VARCHAR(100)" Description = "TEXT" [Tag] Name = "VARCHAR(100)" [Comment] Title = "VARCHAR(100)" Content = "TEXT" Author = "VARCHAR(100)" EMail = "VARCHAR(200)"
Further, the relations contained in the UML diagram must be defined in the relation definition file. This looks as follows:
APF configuration
[Category2Post] Type = "ASSOCIATION" SourceObject = "Category" TargetObject = "Post" [Tag2Post] Type = "ASSOCIATION" SourceObject = "Tag" TargetObject = "Post" [Post2Comment] Type = "COMPOSITION" SourceObject = "Post" TargetObject = "Comment"
In order to use the generic or mapper, the object and relation configuration must be stored in two configuration files.


Do you want to add a comment to the article above, or do you want to post additional hints? So please click here. Comments already posted can be found below.
There are no comments belonging to this article.

In order to provide a state-of-the-art web experience and to continuously improve our services we are using cookies. By using this web page you agree to the use of cookies. For more information, please refer to our Privacy policy.