Over the past few months I’ve been working on a large application powered by my vBulletin MVC framework which required me to make several improvements. One of the models I was working with had about 40 fields, and that caused me to generate all the forms dynamically from model variables dedicated to defining forms. 600 lines of configuration per model later, I grew pretty fed up.

After looking around at other frameworks for fun, I stumbled upon Symfony’s use of Propel, which is a code generator for database access. That got me thinking… At least for initial development, 80% of the work is setting up the initial models, controllers and database tables. Making changes to these are also very tedious, so that inspired me to dig a little deeper and see what I could automate.

Continue reading ‘Framework Update’

I have uploaded the latest and greatest copy of the CodeIgniter - vBulletin user integration.  You can find it in SVN, or download it from SourceForge.

My development tools are now being made public! I am moving it all into one project at SourceForge where there will be guest downloads, and SVN access. Only myself and a few other developers will have write access. I am hoping that pushing it all into open source (MIT license) will help it grow and make development easier with vBulletin.

Project Page: http://sourceforge.net/projects/vbdevtools/
SVN Repository: https://vbdevtools.svn.sourceforge.net/svnroot/vbdevtools

Unit testing is a very powerful form of debugging which many developers don’t know about. Once your applications get bigger, it is daunting to make any changes in fear of breaking the entire application. Re-testing the entire application as a whole is both silly and time consuming. Even having to test various components of the application as a user is silly. If all the pieces work, the application will work!

Code should be broken down into small enough chunks (well written OOP) that it can all be executed separately. The idea behind unit testing is programmatically testing all the pieces of your application individually and independently of the next.

Continue reading ‘Unit Testing Introduction’

After doing various unit testing for VDE, I’ve encountered a quite annoying flaw with PHP unit testing in general. You can’t test private or protected functions, since they are being called publicly from the test function.

Since in most cases you are testing a class file with only classes in it, I decided to try a few ways to modify the script to remove the visibility…

Continue reading ‘Unit Testing Private Code’

A few of my friends have asked me about this recently, so I’ll document it here for others as well.

Visibility refers to how an object property or method can be seen or called. The simplest type, and the default (making it the most common) is public.

A public visibility means there are no restrictions to where the variable or function can be called or modified from.

The next one is protected. A protected visibility only allows it to be seen within the class (OR parent/child class) that it is defined in.

Finally, there is private. A private visibility means only the defining class (not a parent/child) can access it.

Continue reading ‘Visibility’

With vBulletin 4.0 blindly around the corner, where does that leave developers? If we start something big, by the time it is ready, it’ll be about time to rewrite the whole thing. Or, if we’re lucky, it will work for a short while, but we’ll have to recode it all shortly after.

The major problem here is the dependency on vBulletin. Since we’re making things for vBulletin, it doesn’t seem like much of a dependency, but it is. One minor change can render a program useless. Having the fate of our work rely in someone else’s hands isn’t the most reassuring thought. Then there’s the whole template editing nightmare.

The other night I was thinking about this, and the idea was to use other frameworks, and only integrate the user authenticate system.

Continue reading ‘Futureproofing Long Term Projects’

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.

Continue reading ‘vBulletin MVC Framework’

The biggest time waster with writing vBulletin mods is working with the product system. To save templates you have to copy-paste and go between several windows. To do anything you have to use their awkward web interfaces.

Last year I toyed with the idea of importing all the product data from the database into the file system, and then wrote a tool that generates the export XML based on the files, rather than the data. It still had a few flaws: you had to run my own script in order to save any changes (to preview or activate them), but at least the data was in the file system. The main benefit here was being able to share the product across SVN or easily back it up.

Continue reading ‘vBulletin Development Environment’