Re: [Template] Design issues

On Jun 11, 2004, at 12:43 PM, Alan Knowles wrote:

Ok - yet another thread - perhaps adding [Template] to the subject would allow those who get too much email to filter it out if they loose interest..

That's probably everyone except you and me at this point. ;-) The code itself is starting to look like something I can understand and work with, now; the code and "separation of powers" is more clear to me, perhaps from poring over it for (two? three?) days now. Not easy for someone who's not familiar with it to get into, I'm afraid. Nitpicks, not substantial: You sometimes refer to provider['Multisource'] and then to provider['multisource']. Are they supposed to be different keys, or is this just a typo? function Template (not HTML_Template)

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: "Hello PEAR, I have a new spiffing template engine it does: a, b, c, d, can I put it in?"

Ugh, yes, I see your point. So we *are* trying for the One Perfect System, eh? At the worst, we would have to ask, "does it extend from Template.php?" and that would sure limit requests.

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

Not sure which of these you're advocating... the first one?

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

It might not even be a wrapper, per se but a "decorator" on the output? (Hope I used the pattern idea properly there.)

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 don't see that it would be hard to document, you do that with generated DB_DataObject classes, and it seemed pretty clear to me. What were the other issues you ran into with that?

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

True point on the elements, blocks, objects, etc, and a good idea. Not sure on the assigned variables, though -- although if the compilers are going to talk through the main Template object, then $data has to be public, and the idea of assigning variables as public properties just got hosed. :-)

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

Agreed on strings, although streams might be nice -- it's php 4.3, but you can build a stream to pull from a DB instead of pulling the string yourself and pushing it to the template system. Just an idea. Not sure how file handles would work, I'd assume like streams. Are streams include-able?

Hacking::: Have reduced the codesize, by introducing the concept of providers throughout, for most of the major codeblocks. - this seems to work really nicely

Yes, it seems much cleaner now. I'm still not sold on the "assign" as a "provider" thing, but that's a small point.

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

Ha! -- 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: a collaborative online documentation system. http://wiki.ciaweb.net/yawiki/index.php?area=Yawiki Yawp: a single-file foundation for PHP applications. http://phpyawp.com/