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

I think this is a pretty good neutral API http://www.11abacus.com/dev/pear/HTML_Template_Interface.phps // to handle constructor-time configurations

    function Template()
    {
        $this->err =& new PEAR_ErrorStack();
    }

Greg may be able to expand on this, but is it required to initialize PEAR_ErrorStack even if it's never used.?? I would presume not..??

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.

The two approaches are: a) extend all engines of a core Interface, with some limited implementation in it.. b) Provide a core Class that implements (or loads as required) the features required by all templates. I'd tend to go with B) as = 95% of of the runtime use of the engine, should use the core class, and no more.. = Less complex to trace and understand the flow and execution of the engine. (easy for newcommers to understand) = the tendency with the extends model is that is appears to focus on the identities of the template, rather than the features. Features of the template engines that I'm aware of: = assiging data (using the engine as a datastore) = load file from a configured path rule (themes etc.) = convert template from markup into PHP... in different ways = executing template with data on it. = plugin - providing runtime functions to the output stage = filters = post processing the output of a template. = loading / grabbing HTML Elements (WACT / Flexy) for manipulation.

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.

there is only one way to assign / store data.. - you either use it, or dont.. (whether this feature should be in the core, or autoloaded is another question).. however, It's not really a specific feature of a Template engine.. 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." :-)

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com