Re: [PEPr] Comment on HTML::Template_Savant

From: Date: Wed, 02 Jun 2004 17:12:16 +0000
Subject: Re: [PEPr] Comment on HTML::Template_Savant
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-29885@lists.php.net to get a copy of this message
Having said that, and without deprecating Alan's good work, I think that "ramping down" Flexy to the Savant level is exactly the reverse of how things should be handled. A "Lite" style package should not be the cut-down version of a larger one, the larger one should spring from the common and smaller base. As such, I still think Savant is a great candidate for PEAR as it provides that common, minmalist base from which other systems can be extended.
I'm not quite sure you've got the figures right there: - Flexy's core class is 820 (450 without comments) lines long Savant is 1620 (825 without comments) lines.. There may still be stuff in Flexy's core that can be moved out of the main class into other classes, compileAll, the element merger, and a few of the less necessary methods. The bulk of the code in Flexy's core class is really about a) set up the options. b) does the template exist (in any of the source folders) c) doing some tweaking on the object prior to outputting.. All the other loaded as required - compiling - assignment (added today) - plugin support (added today) Regards Alan
So in conclusion if we accept yet another template engine API into PEAR we might as well forget what PEAR currently stands for. I think that's maybe a little dramatic -- I, and perhaps others, do not believe that one more template engine, if it gets accepted, will bring PEAR to its knees either in a technical or philosophical sense. Justin Patrin wrote: PEAR is supposed to allow for competing packages as long as they are different. Lots of people use Savant and it makes sense to me to have it as it *is* a very minimal templating engine. And as said in other comments, each of the other engines could even be extensions of Savant, which would be intereting. Now that I've said that, I'd like to say that I've never really liked Savant myself. It's very strange to me to add the extra assign / etc. syntax when you're just using PHP as your template as it is. That's a valid point; many times, you don't actually *need* a template system per se, you just need to have your business logic set up the variables, then include your separate template script at the end. My response to this, in summary, is this: Often, it's convenient and useful to be able to encapsulate the template inside an object so you can to logical manipulations on that object. This is why template systems can be useful. One benefit of Savant, with the exception of the $this->plugin() architecture, is that Savant encourages just such a template system (i.e., one that you can just "include" as regular PHP). For some people that's not an option, but I think for many developers it's a wise move toward simplicity and maintainability. Lukas Smith wrote, regarding the "core similarities" of Savant and Xipe: Sorry I dont get where the huge differences are and I certainly dont get why we need yet another API for this. A proper modular design is what we need. I agree, but I'm not certain the the template systems already in PEAR are in a "proper modular design." I do believe that Savant can fill that role, due to its minimalist nature, but as usual I might well be wrong. Greg Beaver wrote: Personally, I don't think the Smarty-esque filtering code is all that necessary, Technically, the filters are on the generated output, and not pre-compile or post-compile filters on the template code itself. I've had a number of folks say that they like them; for those who don't like them, well, they never come up because they only get loaded when called. :-) and might implement a few features differently from Paul, Doing it over, I would implement a few features differently as well, error checking in particular -- a year of use has revealed some design weaknesses. For example, there's no need for static plugins or static filters, they could all just as well be instances instead of static calls. It would be nice to be able to configure a plugin at runtime, a la the Text_Wiki $conf vars. Some other small issues, too, all of which would quickly make it into a stable HTML_Template_Savant as a "Savant 2". but the crisis over having Savant in PEAR at all doesn't make much sense to me. Nor to me, in a wide sense, but I understand the frustration and annoyance. The technical problems are not the big deal, the structural and managerial points seem to be at greatest debate.


« previous php.pear.dev (#29885) next »