Re: [SMARTY-DEV] Bug in Smarty Compiler concerning constants?

Erk, no, I meant PHP constants simply aren't supposed to be producible
as clear tokens from Smarty. I wasn't suggesting a new behaviour --
that's the way it already is. You found a bug where they are being let
through. 

I can't speak for why it was included in the first place but  an
interface onto constants is consistent with Smarty's conception of
using data provided from outside. It also makes possible a more secure
restricted environment where you don't want the possibility of leaking
any non-passed information from PHP into the user templates. This
prevents, amoung other things, common paths stored in constants (eg:
SMARTY_DIR) from being accessible to template users.

I'm not a huge fan of the $smarty reserved var either, but I don't
think we should make a special case for their handling for if tags.

xo boots

--- Oliver Jones <[email protected]> wrote:
> On Mon, 2005-03-07 at 23:04 -0800, boots wrote:
> > It looks like there is an issue but I believe that Smarty should
> output
> > quoted text rather than a constant token, not? Especially since
> > constants are accessed from the $smarty reserved variable, ie:
> > $smarty.const.CONSTANT.
> 
> Erk.  No.  That would be annoying.  Sure I can understand using
> $smarty.const.CONSTANT etc when using the {$var} syntax as without a
> prefix there would be no way of differentiating between function
> calls
> and constants but that is just plain annoying (and unnecessary) in
> {if }
> tags.  Though understandable if you wanted a consistent API.
> 
> Personally I'm not a huge fan of the whole
> $smarty.{section,const,capture} business.
> 
> Regads
> --
>                    Oliver Jones » Roving Code Warrior
>    [email protected] » +64 (21) 41 2238 » www.deeperdesign.com 
> 
>