[PEPr] Comment on HTML::Template_Savant

Paul Jones (http://pear.php.net/user/pmjones) has commented on the proposal for HTML::Template_Savant. Comment: (In PEPr this time. :-) Hi, everyone, This monster-length response is "compiled" ;-) from multiple sources. Sorry if I missed any particular person or issue in the following, it's not intentional. Norbert Mocsnik wrote: > Greg Beaver wrote: > > > I wasn't talking (and I think Lukas wasn't as well but he can > > correct me) about the templates themselves, only the backend > > variable assignment, template assignment and fetching. Smarty uses > > assign() and fetch(), HTML_Template_IT uses setVariable() and get() > > (sort of) to do the same/similar things. I wonder if it might be > > possible to create files similar to db_wrapper.php found in MDB > > that allows users to change two lines: [..] without having to > > modify the backend logic (only the templates themselves). > > Yeah, we are talking about the very same thing and I completely agree > with you. It would be great to have such a thing in PEAR. Ah, my mistake, I thought we were talking about steps toward a full unification. Sorry about that. (Although my earlier comments stand, about the possibility of Savant being a lightweight base from which to extend other systems.) > I wish I could dive into all of the template engines in PEAR to > summarize the differences between their APIs, so an RFC and/or > wrapper class(es) could be written for them. But imho this should be > done seperately from Savant and Savant should be handled just like > the other engines in PEAR. Next week I'll have some free time to take > a look at this if this is the good way to go. > > Let's see your opinion first. I'd be eager to see the same thing. I have indirectly suggested that Savant, because it is very useful outside the HTML realm, would better be represented under the main category "Template". However, it seems that the researched, unified base template system you talk about above is a much better candidate for that honor. Lukas Smith wrote: > Well I wasnt saying that Savant should have the task of unifying the > entire template section. I said I dont want another API in there. Again, my mistake; sorry for the misunderstanding. > As such I suggested taking the Template engine most similar and using > this as an API example. However I have been saying this for eons now. I think Greg Beaver mentions this below, when he talks about the most common API in the PHP template world: Smarty. As he says, the fact of the matter is that most developers who use templates, for good or ill, use the Smarty API. For me, I think the best API course for PEAR is to follow the API most developers expect -- but I may be wrong here, and certainly there are times when "most common" is not the best course. > When you propose a package into PEAR you have to be aware of what > came before. Even if what came before is not ideal it is important > that we acknowledge the existance of what is there before and > integrate the new things as much as possible. This is something we > ask of every maintainer (as in being open to merging in new > functionality) as well as the proposer (as in being to mergining in > their stuff). This is a core assumption. And in that vein, I really must applaud Alan Knowles for his quick and thorough response within Flexy to the Savant proposal. He sees that I'm serious, that the user need is common, and he is moving on his own to address it. No better response could be hoped for, really. 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. > Again I told you right at the beginning when you started working > Savant that it is essentially Xipe with one less step. I believe that in a broad sense you are correct. However, in that same broad sense, Xipe is essentially Smarty; so, why should anyone use Xipe? They *should* use Xipe instead of Smarty becuase the implementation, focus, and function set are significantly different and match different goals. Xipe has one focus, Smarty has another. I believe the same of Savant and the other template engines already in PEAR: the implementation and focus are significantly different. > It seems to be the case with Flexy as well. This is not how PEAR > should work. Its nice to have a reference implementation, but now its > time to integrate into PEAR. I agree, but I think your ideas of integration are not mine. ;-) > I hope you understand the very fundamental difference between having > Savant added to the template engine mix and adding a few functions to > an existing one or even creating a new package that is called > Foo_Lite following the API of template engine Foo which already is in > PEAR. I do, and I believe I have outlined above my objections (i.e., larger should spring from smaller, smaller should not be a cutout of larger). > 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. Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=83 -- Sent by PEPr, the automatic proposal system at http://pear.php.net