Faryshta
|
I was checking the code of rainTPL3 and it looks extremely amazing. Seems like a very interesing evolution of the rainTPL2.
I noticed that the \Rain\TPL->_check_template( $templateFile ) method returns a string with the full path to the compiled template.
The current {include} tag works this way.
1.- Obtain the class name with a global function.
2.- Create new \Rain\TPL object.
3.- Assign the variables from current TPL object to new object.
4.- Invoke the draw method which can be subdivided in other processes.
4.1.- Extract the assigned variables.
4.2.- ob_start(); //ob_start() was already invoked in the first \Rain\TPL object
4.3.- invoke _check_template method.
4.4.- return ob_get_clean();
From all those process the only one is neccessary. The _check_template method.
So my proposition is to take advantage that this is still a beta and try something different about it.
Invoke the _check_template method directly instead of making those processes described above.
$parsed_code .= '<?php require ".
$this->_check_template("$include_template")
'?>';
So this is a good idea, bad idea or good but dangerous idea? I will try to apply it on my fork but I wanted to ask here first https://github.com/Faryshta/raintpl3
Good day
|
