Re: Re: New thread - Template base class design

On Jun 10, 2004, at 11:58 PM, Philippe Jausions wrote:

$tpl->open('/name/of/template.html'); // or, $tpl->open($fp) - let it accept a file handle as well, // so that custom streams can be used, for both input filtering // and unusual filesystems

I like the fact you thought about it ;-) However, remember that the API itself (as I defined it) doesn't specify what the parameter should be: string, resource, object,...

Per your notes earlier, that's going to depend on the underlying "driver" or implementation, correct?

I would recommend that the assignment question be studied very carefully - Alan's method solves the extract() problem elegantly. If template variable assignment simply meant <?php $tpl = &Template::create('flexy'); $tpl->t = $data; $tpl->thing = &$refdata; ?> and the template in savant would simply reference $this->t and $this->thing. Other templates would compile so that {t} became $this->t, and so on. This would allow very straightforward management. It would mean that ALL private/protected variables would have to be prefaced with _ to avoid overwriting, but that's not a big deal.

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.

Would it? Just assigning public variables without __set() and __get() seems to work OK here.

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...

I think the idea is that the driver, or extended class, or whatever, can take the object properties and convert or import them properly for the individual parser or compiler for that driver. E.g., if we wanted to bring them all into the local namespace, we could use the old Savant way of an extract or variable-variable setting; similarly, another driver could pull them in just by parsing through the template (the IT style).

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, that would be clearData().

All block buildings should be encapsulated into an object. I'd like to point you to http://www.11abacus.com/dev/pear/ITInterfaced.phps for some inspiration... ;-) This means that two classes may need to be defined for this template class design, one for the template (i.e. how to put things together) and a template engine (manages data, compiler...) Because some engines don't necessary require "block building", the template class may not be directly useful. However, filters could be implemented there... This also means that some implementations of the template engines have to be ambivalent when it comes to what they accept in open(); (or openTemplate();)

I think part of the goal is for the base template class to be directly useful in a minimal fashion ... however, Alan may have a different opinion there, I think we had a disconnect about that yesterday.

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...

I think that's a look to the future, not a requirement for now.

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.

Yeah, there are a number of views about that; you're talking about the "declarative" approach, whereas others prefer the "imperative" line. Harry Fuecks and the WACT guys have done a nice analysis here:

    http://wact.sourceforge.net/index.php/TemplateView

-- 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/