[Template] Design issues

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.. Anyway on with the show.. 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?" 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.. ---------------------------------------- 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).. 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.) 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.. Accepting File Handles: - yeah, although accepting strings may be more critical... (And make handles redundant..) PHP5 (yeah lets only work with that - only kidding ;) - the only ++ for PHP5 is really death of copy by reference.. (other than that the rest is really icing on the OO cake :) __set/__get - dont go there it will break setDataByRef() -------------------------------------------- Hacking::: Have reduced the codesize, by introducing the concept of providers throughout, for most of the major codeblocks. - this seems to work really nicely , 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 :) codes in the usual place... http://devel.akbkhome.com/svn/index.php/akpear/HTML_Template/Template.php Regards Alan -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com