Procedural to OOP PHP Blog

[dk1983]

Hi,

 

I know how to code Object Oriented applications but I do not know how to write them!

 

Basically, I've built a blog with HTML/PHP/MySQL. It's made up of functions that each do a specific task. I've then got a switch case structure that calls these functions depending on the value of a $_GET parameter. Pretty simple stuff.

 

However, I'd really like to re write this blog with OO. The thing is, I don't know what classes I should define, what they should do, and how they should interface with each other. I was hoping some expert application designer could help me out here?

 

I don't know if this will help, but here is a list of the functions in my blog. Their names pretty much explain their function.

 

viewCategory();      // This queries the db to display a list of posts in the specified category. Outputs HTML.

viewPost();            // Query the db and display one post as HTML

viewComment();      // View a single comment belonging to a specific post. Called repeatedly for every comment for that post. Outputs HTML.

addComment();      // Add a comment to db. Only called if validateComment returns true (comment is good).

validateComment(); // This makes sure a submitted comment (HTML form submit) isn't empty or full of code etc.

There are also numerous functions that just output HTML code, i.e:

displayAddCommentForm();    // Display comment form

displayCategoryList();            // Query db and output an unordered list of the categories

 

Perhaps someone can offer me some advice?

 

Thanks very much,

David.

[Buyocat]

So you have a number of options.  Lately I have started using objects to do the model and view of my applications, but leaving the controllers procedural.  This requires making a registery which has all the objects that a controller object would be built out of.  I think it makes sense given that most controllers (for instance a page controller) contain untestable, procedural code.

 

That said you can make objects for your controller, and there are some advantages, for instance you can put common behavior in the controller super class (for example, you might put exception handling, input filtering, and logging in the parent controller.)  If you wanted to write some controller objects you have three standard options: front controller, page controller, application controller.

 

A front controller would be a single class which handles all incoming requests.  I don't think you would use just that, but you could use a front controller in conjuction with one of the other types, and have it act as a dispatcher which reads http requests and translates them into page or application controls and method calls.

 

You could make page controllers in which case you would have one controller per a page.  I think there's a lot of sense in this approach (which is what I opted to do, but without the class surrounding it), but there's an obvious downside too.  Namely you have to write a class for each page, so it requires potentially more boiler plate code, and may be harder to maintain.

 

Application controllers would be like several page controllers wrapped into a single class.  Instead of having a class LoginPage with a method execute or something like that which generates the server response you would have a class UserController which had methods like login, logout, register etc.  Each method would represent a page, and any logic common to all user operations could exist in the class.

 

Now, looking at your methods I'm not sure which of the three options would fit you best.  The things you've listed sound like they need to be mixed and matched depending on the page in question.  But they might fit best with an application controller, where you would have a page AddComment which would display a form and have logic for adding the new comment, a page ViewComments which would list any comments, etc.

 

If you'd like to talk about specifics further tell me a little more about what these functions do, because they may be more "model" than "controller".  I hope some of this is helpful, and feel free to ask any questions you have.

[dk1983]

Hi there,

 

Thanks very much for your reply. It is most helpful! Its funny, but on the drive home from work today I thought of your 'Application Controller' method; having separate pages to do the different things. I just didn't have a name for it 

 

I think that is all the help I need for now. I'm going to do some more research on the methods you described and have a go at implementing one.

 

Thanks again,

David.

[redbullmarky]

many of the recent MVC (Model/View/Controller) frameworks are jumping on the "build a blog in 10 minutes" version of the classic "hello world", so you could do worse than check them out. Take a look at CakePHP (http://www.cakephp.org) for starters, as it might provide you with either the answer to your whole problem or at least give you some ideas about breaking down your functions into OOP classes/methods that concentrate on individual tasks.

 

Cheers

 

edit: cake's blog tutorial is here: http://manual.cakephp.org/appendix/blog_tutorial .

[Mastodont]

 

dk1983,

 

you can try first write some simple objects for model layer, such as connection class or CRUD class. They can simplify plenty of code. I agree with opinion objects to do the model and view, but procedural controllers. Small helper objects for validation or form generation are fine, too.