Re: [PHPTAL] Best practices for performance?
On 06-01-2009 at 11:46:58 Alister Cameron wrote: Excuse my ignorance, Kornel. Can you elaborate on what you mean by "not secure"? I use structure a fair bit to return, say, a fully formatted anchor tag. That DOES have the < character in it. Sorry, I wasn't clear. I had in mind "<" character that is not supposed to be a part of markup. How is this not secure? If you've ensured that it's well-formed and all user-supplied data in it has been filtered/escaped properly, then it is secure. My point is that where structure keyword used, PHPTAL will blindly pass through anything, so securing output becomes your responsibility. -- regards, Kornel ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Best practices for performance?
Excuse my ignorance, Kornel.
Can you elaborate on what you mean by "not secure"?
I use structure a fair bit to return, say, a fully formatted anchor tag.
That DOES have the < character in it.
How is this not secure?
(I feel like I should know the answer to this...!)
-Alister
On Mon, Jan 5, 2009 at 10:18 PM, Kornel Lesiński wrote:
> On 04-01-2009 at 00:05:39 Alister Cameron <
> alister.came...@cameroncreative.com> wrote:
>
> Can you please shed some light on what are "best practices" regarding
>> keeping PHPTAL "fast"?
>>
>
> PHPTAL does most of the work at compile time, so after first execution of a
> template, the overhead is minimal.
>
> The best practice is to profile code first! (using XDebug for example)
>
>
> If phptal_path() function shows up on profiler's radar, you can eliminate
> its use by replacing long TALES paths with equivalent php: expressions, e.g.
>
> replace ${foo/bar} with ${php:foo.bar} or ${php:foo['bar']}
> You don't need to change simplest expressions like ${foo}, because this
> case is optimized automatically.
>
>
> If profiling blames htmlspecialchars(), then you can avoid it by adding
> structure keyword to expressions, e.g.:
>
> ${structure foo} is a bit faster than ${foo}, but it's *NOT SECURE* unless
> you're 100% sure that variable will never contain "<" character (especially
> unescaped/unfiltered user-controlled input).
>
>
> Generally such optimizations are not needed and optimizing 'just in case'
> will not give any noticeable benefit.
>
>
> --
> regards, Kornel
>
>
>
>
>
> ___
> PHPTAL mailing list
> PHPTAL@lists.motion-twin.com
> http://lists.motion-twin.com/mailman/listinfo/phptal
>
--
Alister Cameron
Managing Director
Cameron Creative Pty Ltd
www.cameroncreative.com
Creative, Strategic, Innovative... never boring!
___
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Best practices for performance?
On 04-01-2009 at 00:05:39 Alister Cameron
wrote:
Can you please shed some light on what are "best practices" regarding
keeping PHPTAL "fast"?
PHPTAL does most of the work at compile time, so after first execution of a
template, the overhead is minimal.
The best practice is to profile code first! (using XDebug for example)
If phptal_path() function shows up on profiler's radar, you can eliminate its
use by replacing long TALES paths with equivalent php: expressions, e.g.
replace ${foo/bar} with ${php:foo.bar} or ${php:foo['bar']}
You don't need to change simplest expressions like ${foo}, because this case is
optimized automatically.
If profiling blames htmlspecialchars(), then you can avoid it by adding
structure keyword to expressions, e.g.:
${structure foo} is a bit faster than ${foo}, but it's *NOT SECURE* unless you're 100% sure
that variable will never contain "<" character (especially unescaped/unfiltered
user-controlled input).
Generally such optimizations are not needed and optimizing 'just in case' will
not give any noticeable benefit.
--
regards, Kornel
___
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Best practices for performance?
Hi Alister, PHPTAL compiles its templates into native PHP code so the runtime overhead is very low. I don't know much about WP's native templating engine but I think to recall it was just some hooks (php functions) being called by the core. In this case PHPTAL would be a tad slower but not enough to worry about for the average WP based site. Regarding expressions to avoid, tales expressions translate quite directly to equivalent PHP code, so it doesn't matter how complicated the expression is, it'll be as fast as equivalent native PHP code written by an average programmer. One thing to care a bit about is the use of modifiers like the translation or the cache ones, they add some aditional logic to the runtime execution, usually meaning disk access, so they should be used with caution and only when needed. Running more than one instance of PHPTAL for diferent sections will affect a little bit the overall performance, if the WP templating system allows it, check out the "metal" namespace to get two-step/slot functionality. As for the PHPTAL code itself, it could be further improved by eliminating the need to check if a template has been already compiled or not, useful when all templates are already compiled and no longer changed. Besides all that, if someone bugs you about a compiling template engine (such as PHPTAL itself) performance, ask first if they are using an opcode cache like APC, XCache or Zend Optimizer :) greetings, /imv On Sun, Jan 4, 2009 at 1:05 AM, Alister Cameron < alister.came...@cameroncreative.com> wrote: > Hi again. > After an aborted attempt about a year ago, I am now making great headway on > a PHPTAL WordPress theme. This has been a bit of a "holy grail" project for > me, and as someone with limited experience with PHP, a big challenge. > > Good news is I am getting through it and have overcome all the obstacles so > far. > > I know that one of the questions I will be asked from the WordPress > community is about how big a "performance hit" PHPTAL will impose. To that, > I would like to be able to reply with some wisdom from PHPTAL experts :) > > Can you please shed some light on what are "best practices" regarding > keeping PHPTAL "fast"? > > For example, are there certain PHP expressions to avoid? Is there some > acknowledged ugly "syntax" that should be avoided? Should only on e template > object be used or does using multiple template objects for page components > make no real difference to overall performance? > > These are the sorts of performance questions I have and am wondering if > there is any "agreed best practice" out there...? > > Many thanks! > > Cheers, > > -Alister > > PS. If there is anyone here with both a) WordPress experience and b) PHPTAL > expertise who would like to have a look at my theme -- especially to help me > refine and improve it -- I would love to hear from you. > > --- > Alister R Cameron > CEO // Australis Media Pty Ltd > http://www.australismedia.com > > Mob. 04 0404 > Fax 03 8610 0050 > > Click here to find me online: > http://clicktoadd.me/alicam > > ___ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal > > ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
