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.

(more…)

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

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.

(more…)

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…

(more…)

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.

(more…)

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.

(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.

(more…)

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.

(more…)