Universal templating for Kohana 3.1

Hello, dear residents of Habr.

For quite a long time, I worked with various engines, frameworks, and other self-written variants of the PHP progress engine, as a result of which the brain, which was still young and eager for change, put down its own and, as is usually the case, very ambitious impression that everything should be done. Here, absolutely everything.

Delving into such monstrous pieces like Drupal or Joomla, I understood that yes, the abundance of a developed API and the presence of a large number of modules makes such engines indispensable for creating websites of almost any complexity, but moving to simpler things, like MVC CodeIgniter or Kohana frameworks (the latter essentially follows the concepts of HMVC), it was understood that it’s not always convenient to pound nuts with earth-to-earth missiles, and ease not only in handling the code, but also in the work of the site itself, which is called “solves”.
')
At the moment I am working on MVC (or HMVC, to be exact) Kohana framework, in particular, on the branches of versions 3.0 and 3.1, and, trying to find the most complete and elegant solution for an adequate template of the site, I was surprised to find that my Googling skills are morally obsolete, or the results are really summed up, but there is definitely no objective leader for my task.

Having collected some of my thoughts and ideas, I decided to combine them into a convenient and intuitive template system.

I say right away that I will not cite all the code, since it takes quite a few lines, plus, it includes not a description of not only the controller, but also some views, so I’ll tell you the general principle of the template engine with small examples.

At the core of templating is the controller template.php , which must be put in APPPATH.classes / controller /

The controlling controller itself is described as follows:
abstract class Controller_Template extends Controller

Therefore, in order for your controller to use the capabilities of templating, it must be inherited from the manager, for example:
class Controller_Welcome extends Controller_Template

General features template

• meta, script, style - add meta-tags, links to js scripts and css-files.
• Title - Set the page title.
• Bread crumbs - allows you to build a chain of bread crumbs of navigation based on those already created on the way.
• Content - “block” filling in the $ content key variable, which is the main content of the page.
• Regions - “block” filling in content variables for different places on a page, like header, footer, and so on.
• Pager - Simple generation of a link bar on a page based on the number of the current page and the total number of elements.
• Returning three different types of content depending on the request (HMVC, AJAX or normal).

In appearance, the number of functions is not particularly impressive, but I did not set myself the goal (at least for the first time) to create from this functionality at the level of phptemplate or something more cumbersome and comprehensive. The above functions are enough to determine the central system of templating the site, and no longer suffer, and this is the main task that stood before me.

Then I will give a brief description of the frauds in the controller.

Controller operation

In order for our controller, for which we enable templating, not to swear, it is necessary to specify the string parent :: before () in its function before to initialize templating.

During the initiation of the template engine and, accordingly, the automatic execution of its function before the following actions occur:
- Download template config
- Check and install the pager if the page argument is passed
- Creating an “empty” view and zeroing template variables

After these actions, the template is ready for operation and can be launched even without setting any parameters. The launch itself is carried out automatically, without calling any functions like render () or others, which saves us from having to follow the process of content generation.

However, our goal, on the contrary, was to provide us with the ability to easily control the template, right?

To modify the page, you can use the following constructions anywhere in the controller functions:

List of functions provided

• target ($ path) - sets the path for the main view file on which the template will work. If the path is not set, the standard one is taken from the template folder in the views.
• Meta_name ($ title, $ content) - sets a meta tag of the form \ <meta name = 'name' content = 'content' \> .
• Meta_equiv ($ title, $ content) - sets a meta tag of the form \ <meta http-equiv = 'name' content = 'content' \> .
• breadcrumb ($ link, $ title, $ strict = false) - installs breadcrumbs into an existing path. With the $ strict option, the new path is glued to the existing path by default, otherwise an absolute link will be created.
• title ($ title) - sets the page title.
• content ($ html, $ clear = false) - adds a block to the content variable of the page. By default, a VIEW class object ready for rendering is passed to the function, but if the $ clear flag is set, the content is understood as pure html.
• region ($ region, $ html, $ clear = false) - adds a block to one of the regional variables of the page. It works by analogy with the content function, only requires you to specify the name of the region.
• alias ($ region, $ alias = '') - creates an alias for an already created page region. By default, all regions are stored in the $ regions array, and this function allows you to specify a direct variable of the form $ alias
• add_style ($ path) - adds css file. The path is taken relative to the media path specified in the template config file.
• add_script ($ path) - adds js file. The path is taken relative to the media path specified in the template config file.
• pager ($ all) - creates a pager line based on the total number of any elements. If the page is not set, and the function is called, the template engine generates a ruler for the first page.

Minor remarks

The above functions work in any order and act as storage devices for information that is compiled and rendered after the user action has been completed, so there is no need to follow the correct pattern generation sequence.

The functions of generating breadcrumbs, pager and content blocks and regions use my views stored in the template views folder by paths, respectively, breadcrumbs , pager and blocks .

Depending on the type of request by which an action is called, the template engine returns different content. For an HMVC request, this will only be the compiled and rendered content variable of the page, for the AJAX request it will be the same variable but wrapped in json_encode , and the usual request will render the entire page completely.

Total

Summing up, let me say once again that the template engine does not claim to be the best theme engine for Kohana, but is simply a convenient set of ideas for facilitating the management of the page's appearance. I note that there is room to grow, for example, add the ability to render in html or xhtml, screw the unloading mechanism for css-styles and js-scripts into the corresponding style and script tags to display them as a result as text, and not as an AJAX reference or HMVC-request, and many other tasty buns, but it will be done as needed.

Soon this branch will be uploaded to git so that anyone can easily download and update files as the functionality expands, but for the time being I apologize for the link to the file . Modifications and modifications are welcome.

I hope this template engine will help someone and get rid of unnecessary problems.

Thank you all for your attention, I will be glad to hear constructive criticism and suggestions!