I answered a question on Stack Overflow the other day and it inspired me to write a blog post about a lesser known feature of CodeIgniter called application packages. The developer had finished an application and was wondering what the best approach would be for creating a mobile website and API while reusing configuration files, libraries, and models from their original application. Other answers involved dynamically configuring the base_url based on the requested URL which seems like an unnecessary and convoluted approach. I don’t like editing the core when a solution exists within the bounds of the framework. I proposed the usage of application packages as a simple way to create multiple applications that share resources.

For those unfamiliar, adding an application package path in CodeIgniter modifies the list of directories the Loader uses when looking for resources. More specifically, it “instructs the Loader class to prepend a given path for subsequent requests for resources.” Here is an example of adding an application package path:

$this->load->add_package_path(APP_PATH . '/third_party/package_name');

Note that application packages do not need to be located in the /application/third_party folder; they can be located anywhere on the file system.

The add_package_path() method also accepts an optional second parameter for setting whether or not you would like to load views from the package. By default, CodeIgniter will load views from a package. Setting the second parameter to false will stop that. Here is an example:

$this->load->add_package_path(APP_PATH . '/third_party/package_name', FALSE);

CodeIgniter also provides methods for removing an application package path. Here are examples of removing an application package path:

// Remove most recently added path
$this->load->remove_package_path();

// Remove specific path
$this->load->remove_package_path(APP_PATH . '/third_party/package_name');

The documentation on application packages is located under the section on the Loader Class, however I don’t see them utilized (or discussed) very often.

Getting back to the original problem, the solution I proposed was to create two new CodeIgniter instances (mobile site and API) and to add the main site /application folder as an application package when needed. This would provide access to any existing resources that might be needed but still allow the flexibility to create custom controllers and views tailored to the different versions of the application. The only downside I see with this approach is that it becomes difficult to override resources in a package since adding a package prepends the path to the list of directories. The workaround would be to add and remove package paths depending on the file you would like to load.

The developer also raised the question of whether or not using application paths would incur additional loading time for the end-user. I have not run any benchmarks but I would assume that since CodeIgniter is only checking an additional directory for a file the usage of application paths would have a negligible effect on application performance.

As I am still fairly new to CodeIgniter, I write down a lot of tips and tricks that may not be entirely obvious from reading through the documentation. I collect these from various blogs, forum posts, or Stack Overflow questions. Here I have compiled some best practices that I follow when using the form validation library.

Putting form validation in configuration files

This shouldn’t be a secret to anyone, but storing your form validation rules in a configuration file is great way to cut down on the size of your controllers. Anytime I’m not dynamically assigning validation rules and have a list of static rules I like to do this.

Changing default error delimiters

By default, CodeIgniter wraps error messages in paragraph tags, which isn’t very useful. We all know how to change the error delimiters, but we have to do so each time we load the library. Chris Schmitz shares a great tip for changing the default error delimiters. Simply extend the form validation library and set them in the constructor. When the form validation library is loaded your custom error delimiters will be set automatically and you can still override them when you need to.

Creating new validation functions

CodeIgniter’s form validation library provides many useful validation functions, but it is certainly far from complete. One might be tempted to use the callback mechanism for utilizing your own validation functions. The downside to this approach is that you won’t be able to access them from other controllers. If you need to utilize custom validation functions from multiple controllers, extend the form validation class and place your new validation methods there.

Validation functions in models

If you want to take form validation a step further and store validation functions in your models there is a great post in the CodeIgniter forums that explains how to do so. This is useful if you have validation functions that rely heavily on methods in your models or could be considered part of the model. The basic idea is that you extend the base controller with a validation function that calls model functions.

Ordering of validation rules

When setting validation rules, I always make sure to check the order of the rules. I generally put my filtering rules before my validation rules. I also try to put validation rules that don’t require a database query before those that do. It makes no sense to validate the length of a string after you have queried the database to see if it already exists. These are just small optimizations and probably won’t have too much of an effect on performance but is something I always like to check.

I hope these suggestions will be of good use to anyone that is new to CodeIgniter or inexperienced with the form validation library. For those who have used it, are there any tips or best practices that you’ve found to be useful?

It it with great excitement that I announce my first contribution to the CodeIgniter/open source community. gc-qrcode is a CodeIgniter spark for creating QR codes through the Google Chart Tools API. Here is an example that shows how easy it is to create generate QR codes:

// Configure QR code
$this->gc_qrcode->size(350)
                ->data('http://example.com/')
                ->output_encoding('UTF-8')
                ->error_correction_level('L')
                ->margin(0);

// Get URL to QR code
$this->gc_qrcode->url();

// Generate <img> tag containing QR code
$this->gc_qrcode->img();

For those of you who don’t know what a spark is, I encourage you to checkout http://getsparks.org/. Sparks is a package management system for CodeIgniter similar to RubyGems for Ruby. I first found out about sparks in August when I attended CICON 2011. Since then I have been itching to create one. Lately I have been working a lot with QR codes so I decided to package up some code and release it as a spark.

Checkout gc-qrcode on Sparks or GitHub for more documentation or to download the package.