Refactored

Over the past 6 to 12 months I’ve also been creating a MVC framework for vBulletin. I originally based it off the structure of cakePHP, but slowly altered it to suit my needs more, and also to match how vBulletin works more.

If you are new to MVC, the general idea is this: you have models, controllers, and views. A model works with the database, the views are templates, and the controller is like your front-end script which decides what to do. Logic from each section should not fall into other sections — the goal here is to create more reusable code and less code soup.

A controller is similar to a front-end PHP scipt. Let’s think of an item that the application would use… “post” for example. Usually you would use post.php, and use things like ?do=view, edit, add, delete to control which page is shown. In this case, the controller is post.php, and each of those “do branches” is an action. The difference the framework, is the controller would be a parent class to each action. Each action (or controller, to affect all child action classes) can set various configuration options to handle how it does.

The key benefit is the amount of control you have over all the random peices of vBulletin. Whether it’s templates being used, options, phrases, phrase groups, datastore items, or even random classes you use on the side. It is all set at the top of the action. You will never have to second guess anything. Controllers also add various application-flow convenience functions, like redirects and error messages.

The framework starts before vBulletin does, so when you specify a list of templates to use, it will also cache them for you, and then prepare them for use. When you set a list of options or phrases, it will grab them from vBulletin and put them into a smaller (easier to view) array, and also throw an error message if one is missing. You can also set whch models and helpers are used, and they will automatically be ready for use in your main logic functions.

A model (in most cases) an extension of the vB_DataManager class. The biggest difference is some added convenience functions, and the introduction of read functions. Your controller should never contain any queries in it. It should only pass simple functions like “fetch_all” or “fetch_by_title” to the model.

Finally, the view is your templates. A few common vBulletin variables have been extracted into scope (phrases, stylevar, etc), but the general rule here is you only want to use local variables, which keeps things very clean. No crazy long variable names, or template conditions. All you should use for template conditions is $show[’X'] variables. Keep logic out of here. Any dynamic HTML should be generated from the HTML helper.

Helpers are your random classes that simplify common tasks. Whether it’s generating HTML, parsing bbcode, paginating result sets… the helpers are there to do it. You can extend them per-application, or add your own. The goal is to have very concise, reusable code!

All in all, this is an amazing tool which has probably cut off 70% of my work creating large vBulletin-powered applications. I’ve used it for 3 huge projects now, and various smaller ones. When I get some time I’ll write a detailed article explaining how to use it, and eventually add it to a public SVN repository for all to use.