Re: New thread - Template base class design

Philippe Jausions wrote:

Greg Beaver wrote:

$tpl =& new Template(); $tpl->compiler =& new Template_Compiler_Savant(); $tpl->openTemplate('/name/of/template.html'); $tpl->setData('t', $data); $tpl->output();

I would suggest something like: <?php $tpl = &Template::create('flexy');

This makes sense in the PEAR community, although that requires some serious cleanup of the current HTML_Template "directory". However, there is a need to make room for non-text-generating templates. This syntax would prevent another "flexy" template engines under Image... Not that it would be a smart naming choice, but let's keep it in mind.

??? If the user wishes to instantiate a custom template that is named flexy, the user can just pass in an object, as I described in the part you snipped.

I think it's pushing the requirements of the base class a bit too much. There is a risk of being too restrictive for some other implementations of a template engine. Backward compatibility would require the __set() __get() to be working with PHP4, which is not guaranteed.

No, it wouldn't - this would be for a future PHP5-only template. PHP4 templates would not have this feature (no existing templates validate data anyways, this would be a new feature possibility)

Also, templates should also be editable by persons less skilled in PHP, having them require to do a $this-> for every variables may not be a good thing. Certainly enough, this comment only applies to replacement templates...

this again does not apply :). The backend business logic should be written by someone who is good at PHP. The template itself need not be a Savant-style template - the graphics designers could learn a simple format like flexy, and the backend logic would be the same. This is the beauty of the design - if requirements change later (and they always do), the only thing that must be rewritten is the templates themselves.

resetting template variables would be as simple as: foreach (get_object_vars($this) as $name => $val) {

    if ($name{0} == '_') {
        continue;
    }
    unset($this->$name);

}

This would need to be made a method, a user shouldn't know about the internal of a class, especially its private/protected members. Hence the "clearData()" method ;-) But maybe you were talking of its implementation?

yes

In any case, the important thing is direct assignment to members of the template is probably the way to go - it's efficient, direct, and really easy to document. In PHP5, __set() could be used to validate template assignment as well, which is a neat by-product of this design choice.

I disagree on that, this approach would almost likely make PHP5 mandatory...

Again, this would be for a future PHP5-only version. PHP5 will overtake PHP4 very quickly, just as PHP4 overtook PHP3, so I see no real danger, as long as a PHP4-compatible version of the template exists, for those who do not wish to keep pace with technology.

Also, in my views there are two things when it comes to templates: A template itself that describes how things are put together, and a template engine that use the template to actually generate something.

This is taken for granted. Perhaps you misunderstood what I was saying. The template engine would be assigned values, and then the fetch code would simply include() the template, with no need for fancy extract(). The template engine has to assign data somehow. Using a method is both less efficient and clumsy, as the data already exists outside the template engine. Greg