Re[2]: [PEAR-DEV] a question to HTML_Template_IT/ITX maintainers

Greetings, Adam! At 19.09.2002, 18:45, you wrote: AM> I've been working with the current IT class for a while now and I like the AM> way it's templates work. I also like your improvements a lot! I think it AM> would be great to see this integrated into the current IT class AM> (especially hideBlock()). Having worked with the current IT class I have AM> a few concerns that I am curious if you addressed them or not: AM> 1. can variables be replaced more than once in the same template? (i.e.: AM> {VAR1} shows up twice in the template in different blocks and both are AM> replaced with the same value passed into setVariable()). Well, I introduced the setGlobalVariable() method. Variables set by it are substituted into every block and do not trigger the "block empty/nonempty" logic. Great for common directory prefixes, session identifiers and this kind of stuff. AM> 2. can I call get() or show() and have the class do all the parsing for AM> me? This way I don't have to know the names of the blocks in the template AM> and parse each one by hand (setCurrentBlock() and parseCurrentBlock()), IT AM> should handle all that for the programmer (I'm not suggesting making the AM> set and parse functions private as they would need to be used in some AM> cases). It kind of works that way now, but I've been able to break the AM> current implementation. No, I didn't implement anything like this. I don't think it's possible with the current model, either. You either have to know blocks' names and explicitly call parse _or_ embed some sort of info on which data to get into the template itself. Consider the following <!-- BEGIN foo_block; USE Foo::list --> {foo_id} {foo_name} <!-- END foo_block --> Where Foo::list is some callback handle registered with the template object. And of course, internally it will call parse() AM> Adam >> Greetings! >> >> Some time ago (when IT[X] was effectively not maintained) I borrowed >> it from PEAR and made some kind of private fork from it --- I liked >> its API and "ideology" very much. >> >> Now I have a class which is (mostly) API compatible with ITX but is >> alot cleaner, faster and well-tested in production environment. >> >> Advantages over ITX: >> * Transparent caching of parsed templates. I found out (the hard >> way) that findBlocks() call is VERY expensive. >> * faster parse(): fewer preg_replace() calls >> * Addition of "global" variables, hideBlock() method (an opposite of >> touchBlock())... >> >> Disadvantages: >> * One class instead of IT/ITX hierarchy >> * Callback functions are not supported >> * Comments and error messages are in Russian :] >> * Private API, variables and some subtle quirks are NOT compatible >> with ITX >> >> As the class is effectively a rewrite, it is impossible to provide >> simple patches for IT[X]. So a question: are you interested in >> merging my work into the existing ITX code? -- Ñ óâàæåíèåì, Àëåêñåé Áîðçîâ îòäåë èíòåðíåò-ïðîåêòîâ ÎÎÎ "ÐÄÂ-Ìåäèà" http://www.rdw.ru http://www.vashdosug.ru