Re: [PEPr] +1 for HTML::Template_Savant

On Jun 8, 2004, at 9:31 PM, Alan Knowles wrote:

Is this more what you where thinking...????

HTML_Template_Flexy :       (core loader + assigner)
    Flexy.php, Flexy/Assign.php

HTML_Template_Flexy_Plugin : (savant plugin provider)

    Flexy/Plugin.php Flexy/Plugin.*	

HTML_Template_Flexy_Compiler : (standard compilers)

    Flexy/Compiler.php, Flexy/Compiler/Standard ...

(other compiler backends...) HTML_Template_Flexy_Compiler_Xipe : ... eventually... HTML_Template_Flexy_Compiler_Smarty : ... eventually... HTML_Template_Flexy_Compiler_WACT : ... eventually... It may be dramatic, but proposing 'HTML_Template' as a package to replace HTML_Template_Flexy's core package may be worth while, even though it is unlikely to ever provide PHPlib/IT/Sigma etc.. It would make it considerably easier to use the Common Template API that was posted before..

Agreed that a common baseline HTML_Template (or even Template, period, as it need not be restricted to HTML) is a good idea. However, and this is just me, it would seem that a combination of the common aspects of the minimum functions of Flexy and Savant might be a good starting place too, with hooks for functions that we know are going to be implemented by descendants as Flexy or Savant or some as yet undeclared system. I came up with a minimalist outline on my own, and looking at it now, appears very similar to Joshua Eichorn's suggested model. (Sorry for the long untested example code to follow.) class Template { var $_vars; // assigned vars var $_tpl; // path to the template script var $_output; // generated output var $err; // error stack // could later include a $conf array or the like // to handle constructor-time configurations function Template() { $this->err =& new PEAR_ErrorStack(); } function assign($key, $val = null) { // assign scalar, assoc array, or object properties // to $this->_vars by copy ... perhaps add another // method in the baseline for references, or leave // that to extended classes, don't know. // // simple assignment example, easy to handle assoc // arrays and object properties a la Savant here. if (is_array($key)) { $this->_vars = array_merge($key, $this->_vars); } else { $this->_vars[$key] = $val; } } function compile($tpl) { // this will handle pre-compile, compile, and post-compile filters, // and return the path to the actual script to be executed/included. // default is to treat the template as a PHP script already, but // extended classes can do anything so long as they return a path // to the compiled script. return $tpl; } function fetch($tpl) // the equivalent of outputObject() in Flexy { // support Flexy-style "call-time" assignment of one // assoc-array to the template if (func_num_args() > 1) { $args = func_get_args(); if (is_array($args[1]) { $this->assign($args[1]); } unset($args); } // get the template script to be processed // and remove the variable from local scope $this->_tpl = $this->compile($tpl); unset($tpl); // extract all assigned vars, but don't allow $this // so as not to overwrite the object itself if (isset($this->_vars['this'])) { unset($this->_vars['this']); } extract($this->_vars); // buffer, include, capture, and clean ob_start(); include $this->tpl; $this->_output = ob_get_contents(); ob_end_clean(); // filter the output and return return $this->filter(); } function filter() { // just a hook function for output filters, by default // it just returns the output as-is. return $this->_output; } } Obviously this is a simplification, but I think the idea is sound; the class as above has all the functionality necessary for basic and minimalist templates. Under this hypothetical model, there's no need for "backends" per se in the base class, the developer extends the class directly to do what he likes -- it has a fair amount of structure, but is open enough to accommodate a wide range of extended behaviors. The extended class itself may use backends, of course, or add methods to the base, or override the base methods, but the basic pattern and expected flow is clear even in this minimalist model. To my mind, as demonstrated by the above model, there is no need for "assigner" or "loader" objects in the base class; instead, extended classes use the standard assignment model from the base and can build their own loader systems as-needed. Part of the idea is to have a common API, not just a common object from which to load custom APIs, and I think the above hypothetical model serves that idea. As ever, I may be wrong, and am happy to receive criticism; as Patsy once said to Arthur, "It's only a model." :-) -- Paul M. Jones Savant: the simple alternative to Smarty for PHP. http://phpsavant.com/ DB_Table: build RDBMS tables and XHTML forms in one PHP class. http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table Yawiki: your collaborative online documentation system. http://yawiki.com/ Yawp: a single-file foundation for PHP applications. http://phpyawp.com/