Re: [Template] Design issues

Alan Knowles wrote:

As I said earlier, the concept of extended classes providing different template engines, (perhaps instantiated by a Factory method) - rather defy's the point of getting a unified core. (it just encourages different implementations again..) Phillipes goal was really to make the existing engines accessible with a common API, while this is a good idea, it is not really what would be the ideal situation in the future:

Hopefully correct, although originally the scope of the API was wider than PEAR ;-)

"Hello PEAR, I have a new spiffing template engine it does: a, b, c, d, can I put it in?" PEAR's answer: well the unified core does a,b,d - can you discuss with them how to add c to it? or PEAR's answer: you can wrap the core, which provides a and b, but not c or d (but c is in another wrapper, perhaps you can copy work out an obtuse way to use that?) and write a wrapper that provides c and d ontop of core..

Extending the core of something is always delicate. Reftrofitting is a pain and may be contradictory to original designs... My $0.02 here.

---------------------------------------- Initializing: A classic constructor with options seems still the best way to go, with the ability to modify the behavior of any of the backends by setting them.. - I did consider that a Filter wrapper, may be the only class that actually extends the core (as conceptually a filter class wraps the output)..

+1 on that... although it might be useful to have a setOption() somewhere, just in case the user wants to change the behavior of the template engine between rendering different templates.

Setting Data: - you dont really want to start adding random public vars to the core object, - been there done it.. (flexy used to have $flexy->elements, it was a pigs ear of a design decision.. - it was difficult to explain, document and felt like a spare foot that needed chopping off.)

I'm glad you say that. I had a gut feeling that was not good.

The code I described encapsulates all the potential data types (currently: variables, byref, object, elements, blocks....etc.) in the $template->data[] array. - this enables additional compilers to utilize the store for any purpose they deem reasonable..., and for providers to have a common point to share data..

Seems reasonable to me.

Accepting File Handles: - yeah, although accepting strings may be more critical... (And make handles redundant..)

Not sure where you're going there... do you mean to get the template?

PHP5 __set/__get - dont go there it will break setDataByRef()

Same as above, glad you said that ;-)

I've had a look at Sigma, in terms of implementing it.. with an API thats wider than the QE2, it looked like a bit of a challenge.. There's an example in the top of the code (I think it actually looks cleaner than the originally (but that's taste :)

Nah, you basically need just a couple of things: 1. Encapsulate the block building process into an object, 2. Pass the template engine as a reference to that object, 3. Provide a getData() method in the template engine so the object can retrieve information... could have getDataByRef() or whatever, or make $this->data array public... 4. Have the template engine call the object whenever output is needed... Your open() method of the template engine would then take that object... That's the only way to go with IT/Sigma... IMHO and still have a unified interface...

http://devel.akbkhome.com/svn/index.php/akpear/HTML_Template/Template.php

Looks pretty good to me. -Philippe