[geeklog-devel] caching template library

Tony Bibbs tony at tonybibbs.com
Fri Nov 2 12:08:24 EDT 2007

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.


----- 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. :-)





------- 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?


----- Original Message ----
From: Joe Mucchiello <jmucchiello at yahoo.com>
To: geeklog-devel at lists.geeklog.net
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

> 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 
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net

geeklog-devel mailing list
geeklog-devel at lists.geeklog.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20071102/f9a77dc6/attachment.html>

More information about the geeklog-devel mailing list