Template Library Version 1.2.1

[eluser]Colin Williams[/eluser]
[url="http://ellislab.com/forums/viewthread/88393/"]Template Version 1.3 has been released.[/url]

Template Library Version 1.2.1 has been released. Version 1.2.1 fixes a major bug found in 1.1 and 1.2 with the add_css() and add_js() methods. Upgrade RECOMMENDED.

-------------------------------------------------------------------------------------

Visit the Template Library Homepage

View the Change Log

Still using Template 1.2? See the Ignited Code thread covering Template 1.2

-------------------------------------------------------------------------------------

The Template library, written for the CodeIgniter PHP-framework, is a wrapper for CI’s View implementation. Template is a reaction to the numerous questions from the CI community regarding how one would display multiple views for one controller, and how to embed “views within views” in a standardized fashion. In addition, Template provides extra Views loading capabilities and shortcuts for including CSS, JavaScript, and other common elements in your final rendered HTML.

Using Template looks like this:

Code:

$this->template->write('title', 'Introduction to Template');
$this->template->write_view('content', 'blog/posts', $this->blog->get_posts());
$this->template->render();

Look interesting? Head over to the Template Library Homepage to begin using Template in your next CodeIgniter application.

[eluser]Rick Jolly[/eluser]
Hi Colin. Could you explain the advantages of the Template library in comparison to CI's default method?

Template Library:

Code:

$this->template->write('title', 'Introduction to Template');
$this->template->write_view('content', 'blog/posts', $this->blog->get_posts());
$this->template->render();

CI default:

Code:

$data['title'] = 'Introduction to Template';
$data['content'] = $this->load->view('blog/posts', $this->blog->get_posts(), true);
$this->load->view('template', $data);

[eluser]Colin Williams[/eluser]
Sure, Rick. When one starts using views, they realize they can achieve segmenting views and load results of those in to a master "template" view, like your rewriting of my example shows. However, components of this master template view often don't change between Controller methods, or even controllers. To address the former condition, we can extract or $data array out to a property of the given controller:

Code:

class Blog extends Controller {
   var $tpl = array('title' => 'Introduction to Template');
  
   function index()
   {
      $this->tpl['content'] = $this->load->view('blog/posts', $this->blog->get_posts(), true);
      $this->load->view('template', $this->tpl);
   }
}

What Template and other similar Libraries do is abstract that out one level further. A region in my Template Library is no different than an item in a $data array that is passed to views. However, it is available for manipulation in a greater amount of contexts. Also, multiple calls to write to a region will concatenate the content--again, not impossible with vanilla CI and views, but there's slightly more overhead when having to be keen to the given context. And a feature I built into Template that I call Cascading Views, by which you can provide fall-back view files if the requested on doesn't exist, for example, is something you won't find in CI's Views implementation.

Some people will never have a problem working with Views and View data in the manner you showed. Some people will. Others, like myself, just like the abstraction that such a library affords (and I personally like the metaphors and syntax Template promotes.)

It's a free-for all with how you manage Views and View data. Template standardizes this management for those who prefer it standardized.

[eluser]Colin Williams[/eluser]
Also, I might as well quote from my own user guide:

Template is right for you if

* You feel like using views can be clunky, especially when "embedding" views.
* You don't like calling header, footer, and other global views from every Controller method.
* You prefer having one "master template" that can be changed for any controller in order to meet unique application design needs.
* You don't want to drastically alter the way you interface controllers and views.
* You like clear, thorough documentation on par with CodeIgniter's User Guide.

[eluser]stuffradio[/eluser]
I might check it out

[eluser]sikkle[/eluser]
I think you did a great job writing the documentation, good luck with your stuff.

[eluser]Milos Dakic[/eluser]
Is it possible to change the extension of the template files? From template.php to template.tpl or something similar?

[eluser]steel_slasher[/eluser]
Looks really good, but from what i could see it would be hard to intergrate into my current project

[eluser]Colin Williams[/eluser]
Sure, Milos. Name your template whatever.tpl and in config/template.php, set:

Code:

$template['group']['template'] = 'whatever.tpl';

If Views can handle it, Template can handle it (Template is just an interface to Views.)

[eluser]Colin Williams[/eluser]

Looks really good, but from what i could see it would be hard to intergrate into my current project

Totally understandable and expected. It is definitely an approach one wants to consider up front. With a large project running just fine using standard Views loading, there isn't a lot of sense in refactoring to use Template, unless specifically needed/warranted.

Also remember that Template and Views go hand-in-hand and can exist side-by-side, method-by-method. Say an app needed a new/alternative output format, say RSS or some bespoke XML, Template could be loaded and used in only the needed contexts.