As of late I have been using Laravel a lot to build my applications. I recently ran into the issue of needing to embed a non-Blade view into a Blade layout. The reason for this was that I was using Ember.js, which uses Handlebars.js templates. Handlebars.js templates, much like Laravel’s Blade templates, use {{ and }}. Including Handlebars.js templates in a Blade template did not make Laravel happy. My solution was to create a regular view file that contained my JavaScript templates. The issue I ran into was getting the view embedded into my layout.

Most of my Blade templates looked something like this:

@layout('layouts.common')

@section('content')
    <!-- ... -->
@endsection

Breaking this down, it does two things. It declares that we are using the layouts.common layout and embeds the content section into the layout. How can we do this without using a Blade template?

The documentation explains how to specify a layout using the layout property of a controller:

class Ember_Controller extends Base_Controller {

    public $layout = 'layouts.common';

}

Embedding the view into the layout isn’t as obvious. Digging through the API, I discovered the \Laravel\Section::inject() method which lets you inject inline content into a section. Using this I was able to inject the contents of my view into the content section (@yield('content')) of my layout.

class Ember_Controller extends Base_Controller {

    public $layout = 'layouts.common';

    public function action_index()
    {
        Section::inject('content', View::make('ember.index'));
    }

}

As a side note, Laravel is an awesome framework with some great documentation. But if you look a little deeper and check out the API, there are some really useful methods that aren’t documented.

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.

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.