[geeklog-devel] caching template library

Gary Moncrieff garymoncrieff at googlemail.com
Fri Nov 2 12:32:17 EDT 2007


Just to add my 2 cents

Havent had time to test Joe's library and wont have anytime soon but having
used systems which employ the smarty engine I am all for it.

Dazzy


On 02/11/2007, Tony Bibbs <tony at tonybibbs.com> wrote:

>

> Joe's improvements are definitely better than nothing.

>

> My issues are more strategic but I guess those sorts of issues are for

> Dirk to sort out.

>

> --Tony

>

> ----- Original Message ----

> From: "geiss at midnightforce.com" <geiss at midnightforce.com>

> To: Geeklog Development <geeklog-devel at lists.geeklog.net>

> Sent: Friday, November 2, 2007 10:42:47 AM

> Subject: Re: [geeklog-devel] caching template library

>

> Just to add my 2 cents, as a theme guy. Lots of little templates scare me.

> Yeah, I've invested the time to understand the GL template system as it now

> stands, but I think one of the reasons why historically there hasn't been

> much theme development for GL is the sheer amount of files used in a theme.

> It scares people away (even though, for the most part one only ends up

> touching a handful of the files).

>

> I would be in favor of a system that allows as few template files as

> possible. Even (like Joomla, Drupal, et al.) if one has to mix PHP and

> (X)HTML code in the template files.

>

> I am also in favor of a system (Joe's or otherwise) that speeds up GL page

> rendering. I don't pretend to know what you guys are talking about with PHP

> caching, etc. but at the end of the day, if it speeds up a site, then I'm

> all for it. :-)

>

> Thx!

>

> Eric

>

> ------- Original Message --------

> Subject: Re: [geeklog-devel] caching template library

> From: Tony Bibbs <tony at tonybibbs.com>

> Date: Fri, November 02, 2007 6:58 am

> To: Geeklog Development <geeklog-devel at lists.geeklog.net>

>

> Couple of notes:

>

> 1) Lots of little templates is a big problem. In order to adjust the

> layout for a specific page you have to touch a bunch of little files. Having

> as much of the HTML in as few files as possible make maintenance easier.

> Even though you may reduce some of the I/O you are still stat'ing each time

> you need one and because of how this is put together opcode caching with

> something like APC won't help you at all.

>

> 2) The fact you say escaping output is meaningless concerns me A LOT. Just

> peruse a few PHP-related XSS security posts and you'll find a large number

> of them could have been prevented with escaping th e output alone. Sure that

> leaves open the point that the JS, etc shouldn't have gotten in the DB in

> the first place so input filtering is part of the equation. If security is

> pointless to you then, yes, escaping is pointless.

>

> 3) I don't condone putting a lot of PHP code in templates. Simple loops,

> IF's and handy method calls is all you need. This is surely a philosophical

> thing with you so it's pointless to debate (is as much of the discussion

> between you and I).

>

> 4) Someone (you) still has to maintain all this mess. I'd rather let a

> team of people that are already committed to maintaining a template library

> do that work.

>

> On to another point...Dirk, you brought all this up where you at, baby?

>

> --Tony

>

>

>

> ----- Original Message ----

> From: Joe Mucchiello <jmucchiello**@yahoo.com<http://email.secureserver.net/pcompose.php?aEmlPart=0&type=reply&folder=%0A%20INBOX&uid=2944#Compose>

> >

> To: geeklog-devel**@lists.geeklog.net<http://email.secureserver.net/pcompose.php?aEmlPart=0&type=reply&folder=INBOX&uid=2944#Compose>

> Sent: Friday, November 2, 2007 1:02:50 AM

> Subject: Re: [geeklog-devel] caching template library

>

>

> At 02:25 PM 11/1/2007, Tony Bibbs wrote:

> > I hear you, I agree mostly with everything which has to be shocking

> > for even you given we don't see eye-to-eye at all. Much of the

> > inefficiencies of the current PHPLib is the fact it doesn't support

> > looping and basic IF logic. The result is we have a ton of tiny

> > templates which could go away and we get back the I/O required to

> > open/close then open/close, etc. So yes, what I am suggesting is a

> > wholesale switch which would require significant code changes. That

> > doesn't bother me because of what you get in the end.

>

> I actually think my changes eliminate that. Remember inside the PHP

> engine the second call to "include" doesn't hit the file system, it

> accesses the already encoded data structure created from the prior

> include. So making little templates is not a problem. In fact, I think

> the expensive part is the "new Template()" call. Do that in a static

> (for often created templates, such as one that might handle

> select/option style stuff) and you cut down the overhead even more.

>

> Also, Geeklog doesn't take advantage of the set_block stuff as much as

> it could. That would cut down on the number of individual template

> files.

>

> > And as far as escaping output by default, that is a requirement in

> > my opinion. I don't care how many :h's you do...when you do a :h

> > (or whatever syntax it is) you have to ask yourself hey, do I really

> > want to allow HTM L/JS, etc? It errors on the side of

> > security...another GL trait.

>

> And GL often drops intended backslashes because it over processes

> certain strings. GLs string handling is atrocious at times. Too much of

> GL generates HTML and stuffs it into a single template placeholder

> variable. Those variables must ALWAYS be :h. :h is not a choice made by

> the theme maker, it is made by the coder. Until you break the coder of

> the habit of taking that decision away from the theme maker, the need

> for defaulting to htmlspecialchars is meaningless.

>

> > As for the lang stuff...happy will be the day that $LANG01 goes away

> > complete for something actually readable. But if we get the template

> > thing licked I can hold off on that complaint.

>

> Do you also dislike $LANG_ADMIN['save']? $LANG01 is obviously lacking

> but later day $LANG variables aren't so cryptic.

>

> > Also, don't forget the ability to call functions...not being able to

> > do that is a real f'n pain.

>

> And as I said, my library lets you put <?php echo blah(); ?> anywhere

> in any template now. Can't beat that, really.

>

> > It's a matter of When not If this happens. To me this is a question

> > of being lazy and taking the easy route or biting the bullet and

> > reaping the benefits.

>

> I don't see the When. All the thing you talk about make me wonder why

> you are bothering with a template library at all. Where's the template?

> You want to call a function? You want loops and ifs? Why are you

> creating an interpreted language and running it under PHP? Set_block

> can usually solve the looping problem.

>

> But, I think we've drifted off topic. Your When certainly won't be part

> of 1.5.

>

> __________________________________________________

> Do You Yahoo!?

> Tired of spam? Yahoo! Mail has the best spam protection around

> http://mail.yahoo.c om <http://mail.yahoo.com/>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel**@lists.geeklog.net<http://email.secureserver.net/pcompose.php?aEmlPart=0&type=reply&folder=INBOX&uid=2944#Compose>

> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

>

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel**@lists.geeklog.net<http://email.secureserver.net/pcompose.php?aEmlPart=0&type=reply&folder=INBOX&uid=2944#Compose>

> http://eight.pairlist.net/mailman/listinfo/geekl og-devel<http://eight.pairlist.net/mailman/listinfo/geeklog-devel>

>

>

>

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20071102/4d080cbf/attachment.htm>


More information about the geeklog-devel mailing list