Module for hierarchical representations (View) for Kohana

This is about my first module for the Kohana framework.


I admit honestly, at the first and subsequent views on this framework, I really liked it. But as you know, nothing is perfect. As it seemed to me, one of the weakest points in Kokhan is a rather primitive view (View). In essence, they are a plain-php file with exported variables in the global scope and a controller accessible via the $ this link. This is very convenient, when you need a view to output data, there is nothing superfluous, you can focus on the code. But when we need to display a page layout with a complex arrangement of elements that can vary from section to section ... What should I do? Collect all of the small views in the controller? It is not convenient, especially if there are many controllers - God forbid, for example, the number of columns in the markup will change, you will have to redistribute blocks with content in each controller in each controller. Probably for this in version 2.4 there will appear (I hope) a module for integration with Smarti.

I decided to search a little on this topic and found a very interesting topic on the forum of Kokhany , which made me think. By default, we have linear representations in the form of an incl file. We need inheritance, modularity and a clear hierarchy of representations. I know only one entity ideally suited for this description - these are classes :) In the above topic, the author just says that he uses this approach for his framework. It was a small matter - to write the plan :)

One of my requirements for myself was that you could not completely abandon the usual ideas, because in some cases they are really convenient. I managed it. Moreover, I even managed not to use custom add-ins like MY_View.php for the main classes. This is a plus because no one knows at what difficult time they can be useful to you yourself.
')
My implementation is based on the inheritance of a new class from View:

class Inherit_View extends View {

protected $class_name = NULL;

public function set_filename($name, $type = NULL)
{
parent::set_filename($name, $type);

// no slashes allowed in class names.
$ this ->class_name = str_replace( '/' , '_' , $name). '_View' ;

return $ this ;
}

public static function factory($name = NULL, $data = NULL, $type = NULL)
{
return new Inherit_View($name, $data, $type);
}

public function render($print = FALSE, $renderer = FALSE)
{
// Load the file with view only once
require_once($ this ->kohana_filename);

ob_start();

// Merge global and local data, local overrides global with the same name
new $ this ->class_name(array_merge(self::$kohana_global_data, $ this ->kohana_local_data), Kohana::$instance);

$output = ob_get_clean();

return $output;
}
}

* This source code was highlighted with Source Code Highlighter .

I intentionally reduced the render () code here so as not to take up much space, the omitted code is no different from View :: render ();
If in a nutshell, the class does the following: Intercepts the name of the view, even before the path and extension is added to it and stores it as the name of the future class + '_View' at the end. When rendering a view, a class with a saved name is simply created, to which all variables and the current controller are transferred. I also overlap the factory, so that when Inherit_View :: factory is accessed, it was Inherit_View that was created.

Now to create a view with a hierarchical structure, simply call new Inherit_View ('Template'); and in the Template.php file, the Template_View class inherited from Base_Inherit_View, which in turn inherits from ArrayObject from SPL, must be declared, and therefore access to any field inside Template_View is done as $ this-> property or $ this ['property']. And $ this-> controller contains a link to the current controller.

I included in the examples demo views Html_Strict_View, Simple_Page_View, Another_Page_View, I think looking at them you can easily understand how many advantages such a wrapper of views gives. I also included in the Inherit_Template_Controller module, similar to Template_Controller, only creating not a View, but an Inherit_View. And of course, according to the tradition of other modules, I turned on the demo controller. Full combat set, in general :)

Of the downsides of this approach, I can only note that if your coder is not you and he does not know PHP, he will most likely send you :) But I most often create them myself, therefore I get only advantages from this approach.

Link to the module in the beginning of the article and here . To make the module work, do not forget to enable it in $ config ['modules'].

Thank you nex for pushing for thinking and asking the very first question, why it’s so bad with ideas, without him I probably wouldn’t do it.

Thank you all very much!