Lukas Smith [2004-06-01 18:23 UTC] As I have always said there is no fundamental difference in Xipe that would prevent it acting and feeling much like Savant. Therefore I much prefer to see a merge, especially since our template category is a mess as it already stands.
All that needs to happen is to add your plugin system and make the compile step optional. AFAIK Xipe just replaces its own simplified markup with php code and in the end the actual "magic moment" where the data meets the template is more or less the same in both Xipe and Savant.
I am not 100% sure on that but IIRC the caching was just for the compiling.
David Costa [2004-06-01 18:37 UTC] I have been using Savant for a while and it does has merits.
as Paul said :
"Xipe uses variables directly from the script, without a step for
"assigning" them to the template; Savant uses an explicit "assign()"
method to push variables to the template.
Xipe implements its own cache. Savant leaves caching for the application
and does not try to override that."
Therefore I would see Savant as a good alternative to the existing template engines.
True, I realise that some PEAR developers don't like the idea of another template engine. But frankly I have been trying ALL the PEAR templates, smarty, many others and really Savant is different. I don't want to use a compiling/caching engine ;)
You can be up and running in minutes and there is nothing to learn. The no compiling and special markup is a great thing. I have checked the source and is well commented and structured so, for me it would be a +1
Regards
David Costa
Lukas Smith [2004-06-01 18:41 UTC] Let me clarify that I dont have any technical opposition to the code. The point is that to me its a Xipe_Lite or whatever. I just dont want yet another template API in PEAR.
Paul Jones [2004-06-01 18:42 UTC] Lukas said, regarding the "cache" function in Xipe:
> I am not 100% sure on that but IIRC the caching was just for the compiling.
Lukas, you recall correctly; I am mistaken in the final portion of the proposal and will rewrite. The Xipe cache is not for output, but for the compiled template script.
Everyone else: note that Savant does not compile templates into scripts; the templates *are* scripts. Thus, Savant does not require a cache of any sort, whether for compiling scripts or caching output.
Greg Beaver [2004-06-01 20:13 UTC] Lukas has a point: how hard would it be to provide API aliases to existing PEAR templates? This could even be in optional wrapper classes in separate files that extend Savant.
All templates would have to be rewritten, but their code might remain the same.
Greg
Paul Jones [2004-06-01 21:03 UTC] Greg Beaver said, in response to Lukas:
> how hard would it be to provide API aliases to
> existing PEAR templates? This could even be in
> optional wrapper classes in separate files that
> extend Savant.
This is an excellent point. Savant is flexible enough, with its plugin and filter architecture, that it might serve as a base class to mimic other template engines. This is not something I'd like to do by myself, but it could be done.
For example, to make Savant do a simple find-and-replace on tokens, you could write an output filter to look for "{$...}" and replace with the assigned token value.
Similarly, if somone else likes to use TAL-like tags, Savant could act as the base for variable storage and assignment, and an extended Savant (or even an output filter) could look for "<tal:var_name>" or "<tal:loop_name>...</tal:loop_name>" and apply the appropriate logic.
Likewise, if internationalization is your thing, you might write a plugin that places the proper text at runtime, or a filter that applies a GetText method to the entire output at once.
Indeed, one could extend Savant in any number of ways to get the same results as most if not all the existing template engines in PEAR; I'm certain there would be some differences, but on the whole and in the main, it might be do-able. Just not by myself alone. :-)
Now that Greg brings it up, it seems to me that if PEAR is looking for template system unification, Savant might be a good base to start from, becuase it has the most powerful template language available to it (PHP itself) and has such a flexible plugin and filter architecture -- and all without compiling!
Perhaps I am overly enthusiastic about the idea. :-)
Paul Jones [2004-06-02 00:33 UTC] Norbert Mocsnik wrote this in reference to Savant being the base for a common PEAR template engine:
> Although it would be good to see a common API for the template
> engines of PEAR, I don't feel it has to be done now, with Savant.
> I'm using Savant since a week and it worked great from the
> beginning. As it's fully PEAR-compatible (hence the proposal), I'd
> be happy to see it in PEAR to use the common bug system, manual,
> whatever.. I think Savant should be allowed to be in PEAR as it's a
> great tool and it's just as good as the other 5 template engines.
> When someone someday comes up with the idea of contributing
> something regarding to API-unifying, he/she will be allowed to do
> it. I don't see why this should be solved in Savant when the other
> engines doesn't solve this.
I think that Greg and I are saying that it *could* be done, *might* be done, using Savant, not that it *must* be done. To be clear, I'd rather not have "must unify all existing PEAR template engines" as a requirement, that's just too heavy a load for me to bear. However, the technical possibility does exist, due to Savant's flexibility, for Savant at some point in the future to be able to mimic other template engines' APIs and markups.
And thank you for using Savant, Norbert; it will stay around whether or not it gets accepted into PEAR (which I hope it does :-).
Alan Knowles [2004-06-02 02:05 UTC] From what I can see. to add this as a backend to Flexy:
a) improve / replace the HTML_Template_Flexy_SmartyAPI class (which does the assign/... etc. wrapper...
b) add driver savant
c) modify compiler() so that driver savent just sets the $compiledTempate = $sourceTemplate
d) add an option or method output() to use extract, before including the template.
Alan Knowles [2004-06-02 05:08 UTC] OK. - the core integration work is done on Flexy
$flexy = new HTML_Template_Flexy(
'templateDir' => '/location/of/templates/',
'compiler' => 'raw',
...
);
$flexy->compile('savant_template.php');
$flexy->assign('xxx','yyyy');
$flexy->output();
It still needs some work:
- plugins - I've not added any, as the licences are different.. so it needs approval to work together on this.
- plugins - There is some nasty code in the Savant loader that works around bugs in constructors (which should not be there, as far as I can see, its a design problem in plugins, that they shouldnt use php constructors..)
- assign - I've not added assignObject as It's not clear how it works.
- filters - dont seem to add much value at present, and could really be extracted from the codebase, and added as a seperate package (letting the user filter the buffered Output)
Lukas Smith [2004-06-02 06:59 UTC] 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. 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.
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.
Again I told you right at the beginning when you started working Savant that it is essentially Xipe with one less step. 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 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.
So in conclusion if we accept yet another template engine API into PEAR we might as well forget what PEAR currently stands for.
David Costa [2004-06-02 10:04 UTC] As Justin said "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 interesting."
Now Flexy is a simplification of Xipe but is part of PEAR:
"HTML_Template_Flexy started it's life as a simplification of HTML_Template_Xipe.."
I have been using Savant. Before using it I tried Xipe, Flexy, Sigma and many other engines including smarty.
Savant is different in his approach to templating. Now if we want to find similarities, this would be the case on Xipe and Flexy too because the result might look the same. Afterall these are all template engines.
Norbert and Justin seems to agree with me. Now, there are 2 possibilities. If competitive package means "doing the same thing" or "having the same results" there are already different template engines allowed in PEAR. If it means "doing the same thing but with a different approach" in my opinion Savant will be deem to be considered.
I would probably be as negative as others but I tried it, checked the source, and it is hardly the same as Xipe.
Lukas Smith [2004-06-02 10:35 UTC] Please dont use the existing template engines as an example of what we should have in PEAR in the future. I think its widely accepted within the community that the template engine category is a mess. Using this mess as a reason to do to the mess is obviously not a good idea.
When I say mess I am not talking about that either of the template engines themselves are a mess. I am saying that a sufficiently modular approach is what we should have done all along.
For example the compiling step in Flexy and Xipe is obviously very easy to make optional without making anything "heavier" for people that dont use this feature. At the same time it should be trivial to make a plugin system truely optional as well.
I have looked at the source as well and at its core its the same thing.
[compile]
[pre filter]
set variables
ob_start()
include
ob_get_contents()
ob_end_clean()
[post filter]
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.
Greg Beaver [2004-06-02 12:35 UTC] I'd like to point out that Paul's API decisions were very clearly structured around what his users wanted.
Although we tend not to acknowledge this fact, Smarty is the only template engine that about 90% of PHP users use. Paul's API is compatible with the Smarty engine. I don't see anything stupid or disrespectful about that choice.
Those of you who use template engines only for web pages probably don't see the reason for a non-compiling template engine, but then again, none of you have coded a large-scale application like phpDocumentor.
Redistributing compiled templates is a complete nightmare.
1) compilation by definition interprets what you've done, so templates often behave differently than you think they will. The process of learning a new template language causes countless bugs still to this day in phpDocumentor templates
2) if you forget to compile a template, your application doesn't work in a shared environment because users don't have write access to the compiled templates directory.
3) doing anything meaningful in a template language requires tremendous power, and the complexity of a template becomes extremely difficult to debug or maintain, as the language is usually limited for security reasons.
These three headaches have caused endless annoyance for phpDocumentor development.
Personally, I don't think the Smarty-esque filtering code is all that necessary, and might implement a few features differently from Paul, but the crisis over having Savant in PEAR at all doesn't make much sense to me.
However, I should add that I do like the direction Alan is taking Flexy with the recent commits, this seems a good decision, one that other template engines could learn from. Supporting competing APIs and features is always a good thing. I didn't mean to single Savant out with my last comments about supporting competing APIs - this is something all competing packages should do. Simpletest is another example of a great package that supports competing APIs. Any other propietary API design is too close to Microsoft for my tastes :)
Alan Knowles [2004-06-02 12:40 UTC] have a look at the modified test files:
http://devel.akbkhome.com/svn/index.php/akpear/Savant_tests/
1-4 work ok. (See comments for changes)
5 - relates to filters, I'm not sure that it's the job of the template engine really.. - still needs some thought..
6 - paths are not relivant, that is done in flexy by setting options['templateDir'] to an array. and/or using multiSource (for themes)
There where quite a few modifications
* plugins are now single files with many methods - as the base (although the old style still works)
* plugins dont send the template engine in the method (it's avaialbe as a class var anyway)
* getTokens is flexy->assign->variables
* ->plugin returns only, you have to echo it.. it seemed pointless bloating the API just to provide a echo on it.
Paul Jones [2004-06-02 16:41 UTC] (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.
Lukas Smith [2004-06-02 17:29 UTC] Paul, your assumption that this needs to have complex (heavy) things cannot spawn simple (lite) things is flawed. Nor will you have a hard time making a proper argument for this.
Both ways have their merit and usually the one that is taken is based on what was first around. Take Mozilla/Firebird, Cache/Cache_Lite etc. MDB/MDB2 is another example in a way since for the most part MDB2 is just a more modular MDB.
Ondrej Jombík [2004-06-03 14:15 UTC] This is one of the best template engines in PHP.
I would be very happy to see this in PEAR.
When voting will be enabled, you will have my vote. :)
Harry Fuecks [2004-06-03 17:58 UTC] Just throwing in 2c; think Savant is a good addition to PEAR _because_ the templates are written in PHP itself. As such it's "low risk" for users - there's minimal lock in to the template syntax - if someone decides to ditch Savant at a later date, the templates can, more or less, still be used.
That said, also think that http://sourceforge.net/projects/php-templates/ (a PHP extension for templating) should make PECL some day, so perhaps I'm strange.
On the general subject of templating, would like to recommend some reading: http://wact.sourceforge.net/index.php/TemplateView - this document is meant as an objective study of "the template problem" and I can't recommend reading it enough as I think it helps clarify the issues with template engines in PHP and may in making decisions about PEAR's template engines. [Note I've made some contribution to the page but am one of many authors - please feel free to make further mods / additions]
That TemplateView page identifies a number of critical areas which can be used to describe a template engine, these being;
- Marker Style (the template syntax)
- API Style (how you work with the template engine from the calling PHP script)
- Data Population (how data reaches the template)
There are also "Good Template Smells" defined at http://wact.sourceforge.net/index.php/GoodTemplateSmells (this was proposed by Jason @ phpcomplete.com) which further help in evaluation.
Savant can be categorized as;
- Marker Style: Scripting Tags (i.e. PHP) - this makes it unique in PEAR
- API Style: Pinhole API - believe all the PEAR engines use this (compare to DOM, for example, and "getElementById")
- Data Population - push - goes from the PHP script to the template (by contract believe Flexy uses a mix of push and pull, for forms while XIPE seems to be a kind of a "pull" style - include the compiled template then variables you defined in it's scope get there)
Similar categorization could be done for the other PEAR template engines to help analyze how each distinguishes itself from the other.
One critical point I think for PEAR is it should be possible to unify the result of the the HTML_* packages for use in a single PEAR template engine - know there's some work happening in that direction, with Flexy and Quickform in particular - seems like a deciding point in designing a "grand unified template engine".
Anyway - just rambling ;)
Alan Knowles [2004-06-04 03:16 UTC] I do think continuing as a proposal now, is beating a dead horse a bit.
Flexy now does _everything_ that Savant does.. - you are basically proposing a competative package, that's only competative feature, is realistically, that provide a marginally different API...
Paul Jones [2004-06-04 03:23 UTC] Alan wrote:
> I do think continuing as a proposal now, is beating a dead horse a
> bit.
>
> Flexy now does _everything_ that Savant does.. - you are basically
> proposing a competative package, that's only competative feature, is
> realistically, that provide a marginally different API...
That is as it may be ... however, I am going to continue the proposal and let it come to a vote. That way, the Savant question will be defintively be over, one way or another. If enough PEAR-DEV voters agree that Savant is a useful addition, then it will be in; if more think that Flexy can do the trick, then Savant will be out. Either way, it's done and over for all time, and I won't have it in the back of my mind any more.
I'm hoping that Savant gets voted in, of course, but then I'm rather fond of it. :-)
|
