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 <kor...@aardvarkmedia.co.uk
> 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

Reply via email to