[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: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20071102/4d080cbf/attachment.html>


More information about the geeklog-devel mailing list