Re: Play nice! Re: Savant/Flexy/Foo template engines

Hi, Philippe, Thanks for your response. You wanted to split this off to another thread; Looks like Greg beat us to it. I'll finish my reply on this one and move to the next in future; Alan may want to make his answers within this one as well. On Jun 10, 2004, at 7:16 PM, Philippe Jausions wrote:

There's a lot of talk around these template engines... That's good. But the focus gets lost a bit.

Not the first time I've lost focus the past few days. :-(

The API is meant to be accepted by a lot of template engines if possible, ideallistically all of them... ok, that's a bit pretentious, but wouldn't be nice?

Sure would.

Should PEAR mandate a new template base class? Not IMHO.

Mandate? No. Have, and then encourage the use of? I think so, and I think it would be welcome, given comments in this thread and others.

Otherwise, there wouldn't be DB, MDB and so forth... In this view, a template base package may not satisfy different approach to templating. Someone made a comment about the assignment of data by value and by reference saying that the would-be template base class should store them in different private members because "extract()" doesn't work well with references. This implies that the template engine would actually use extract(), which may not be the case.

I think an implementation can be inferred from the existence of certain methods in the base interface; if data is assigned, then it must be placed into the template in some fashion. I suppose one could get around extraction, or importing via variable-variable, by using echo "$this->vars['var_name']" in the template code, but somehow that seems obtuse to me. Do you think that, as Alan has said, that the setData (assignment) code should also be a loadable object of some sort, or do you think it makes more sense to have a single standardized setData() method so that expectations remain the same across all implementations? The differences between implementations on this issue seem very limited to me.

Although some template engines provide caching, I decided to not include that in the API.

I agree completely.

I also saw some discussion about filters. I won't extend on that but filters shouldn't be part of the API.

Yes, I think that was me. Easy to leave them out of the base implementation, interface, whatever we end up calling it; and I can remove them from my example implementation.

It doesn't mean that they can't be used, just that as far as the API is concerned, they should be applied transparently. What could be done is instead of passing a simple file name to the openTemplate(), an object could be passed that would take care of applying whatever filters are needed.

This cuts to another matter: are you saying that you think the entire business of "extraction" (or pulling of values from the base template object) along with pre-processing ("compiling") and post-processing ("filters") should be part of a secondary object? I had thought that only a pre-processor/compiler would be needed; I may need to re-think my position.

At this point, though, I would like to have some common agreement over the definition of the API itself, so I could get other template engines maintainers involved in the process...

I like it; I think it is both generic enough to allow wide use, and specific enough to limit expected behaviors. I reserve the right to ask for tweaks, but in the main it is a really good piece of work. And if nobody else has said it, Thank You Philippe! It's just the kind of thing we need to start template unification. :-) -- 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/