Re: templating, anyone?

From: Date: Sat, 04 Sep 2004 02:17:21 +0000
Subject: Re: templating, anyone?
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33209@lists.php.net to get a copy of this message
What is so horrible about variety? On Fri, 3 Sep 2004 19:13:51 -0700, Sebastian <buddhahead@gmail.com> wrote: > It's already written :| > > > > > On Fri, 3 Sep 2004 20:48:54 -0500, Ryan King <ryansking@mac.com> wrote: > > > > > > > > On Sep 3, 2004, at 1:30 PM, Sebastian wrote: > > > > > Hi! This is my first time writing, so go easy on me :p > > > > > > I've had a couple of conversations with the folks at pear-group and > > > about another templating engine and received their thoughts, but yours > > > matter, too. I'm going to provide some of the conversation (my > > > reasoning behind wanting another templating engine) and see what you > > > guys think. If someone is currently working on a templating engine and > > > would want to implement the things I speak of, I would be glad to help > > > with that project. Otherwise, please consider the following :) > > > > > > ------------------------------------------------------- > > > > > > (Pasted from another e-mail to pear-group) > > > > > > Before you object, I want to let you know that yes, I already know > > > there are tons of templating engines written in PHP, even ones that > > > may implement PHP's native parsing ability. If there are already > > > engines that implement what I have implemented, please point me to > > > them because I have not found any. I wouldn't be requesting if I were > > > able to find something that implemented what I wanted :) Let me start > > > by stating what is wrong with many templating engines: > > > > > > - They are templates on top of templates. Special languages are > > > constructed and parsed to do what PHP already does natively. These > > > types of engines are inherently slow and inconvenient because you must > > > learn X parsing language (and regardless of simplicity, time is > > > money!) > > > - Footprints are too large -- there is usually too much code to be run > > > which adds to the longer load times and poor performance on lower-end > > > machines > > > - While some of the engines I looked at used a method I propose, they > > > used output buffering! And to what benefit? None, that I can see. > > > While some of the engines provided a filtering function, albeit > > > useful, is slow in any implementation that I can think of (more > > > parsing, more memory, less performance.... > > > - Some of the engines whose source I read were very basic but had many > > > of the aforementioned issues, making them undesirable. > > > > > > I made a number of references to engines whose source I browsed: > > > > > > http://www.sitepoint.com/forums/showthread.php?threadid=123769 -- I > > > read source for 16 of the engines listed in the first post on that > > > page -- they all (included a couple of other engines I found on the > > > 'net) had the issues mentioned above. > > > > > > Now, let me talk about what I propose: > > > > > > - Template parsing is done natively by PHP -- no tricky dance moves, > > > parsing overhead, or learning curve > > > - No output buffering, output is echo()'ed (or include()'d, as the > > > case may be) when requested -- this prevents overhead > > > - Nested objects (fun), named objects (eases dynamics of creation and > > > breaks from linear logic) > > > - Locking (quietly prevents others from adding templates when you have > > > finished your page) > > > - Approximately 200 lines of code (most of which is wasted on > > > formatting for readability) > > > - Fundamentals -- the engine I propose is very basic, but this doesn't > > > mean "un-featured." Considering the way it was written and what it > > > does, it provides opportunity for subclassing and scalability -- > > > adding filtering or caching (for example) is only a few steps away > > > (although I realize taking those steps may leads to the aforementioned > > > problems) > > > > > > For most large-scaled projects I have worked with, I have never used a > > > templating application such as Smarty -- usually they were simply too > > > heavy or too complex. Providing such basic > > > functionality would allow one to easily add or change functionality > > > > I definely agree that Savant [http://phpsavant.org] is closest to what > > you're looking for. Even if Savant or Savant2 doesn't do one of the > > things you request, extending would be much simpler than starting from > > scratch. > > > > -ryan > > > > ------------------- > > "There are only the pursued, the pursuing, the busy and the tired." - > > The Great Gatsby > > > > http://homepage.mac.com/ryansking/ > > > > > > -- > > ------------- > buddhahead@gmail.com > -- ------------- buddhahead@gmail.com

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