Smarty

iu2456 · Smarty n00b Joined: 12 Jun 2003 Posts: 1

I'm running smarty with PHP 4.3 in Windows 2000 server, but when run a page I get this:

boots · Posted: Fri Jun 13, 2003 12:29 am Post subject:

what is your question? You have a syntax error in your code.

ZeroFill · Smarty Rookie Joined: 31 Aug 2003 Posts: 28

I have the same problem and it started with 2.6.0-RC3 (works fine if i copy 2.5.0's files back to the dir). the problem is that i have a block that starts in header.tpl and ends in footer.tpl. since it's an "optional" block plugin (only appears if i add ?timeblock=1 to the URI), it looks like 2.6.0-RC3 is using a different method than 2.5.0 so it breaks the script if <{/close}> isnt included.

yes, i delete the compiled dir each time i switch between 2.5 and 2.6

[edit]
actually, it still breaks if i take out the <{if $smarty.get.timeblock}>
[/edit]
_________________
my delimiters are <{ and }>

messju · Posted: Mon Nov 17, 2003 9:01 am Post subject:

boots · Posted: Mon Nov 17, 2003 3:08 pm Post subject:

It looks like ZeroFill is using the technique for timing using my older {timeblock} template timer. He's already posted into the thread for Total page generation time where I posted what I thought to be a better technique that also avoids explicit blocks.

I think we can live without this "feature".

ZeroFill · Smarty Rookie Joined: 31 Aug 2003 Posts: 28

messju · Posted: Mon Nov 17, 2003 3:42 pm Post subject:

the point is, that smarty 2.5.0 treated {block} and {/block} as merely two single entities.

so "{block}...{/block}...{/block}" for example didn't lead to syntactical incorrect php, just to weird behaviour.

in the long run i'd like to make smarty's compiler check more syntax (like proper nesting of blocks). this is only feasable if we enforce the opening and the closing tag in the same file.

i always hate to break compatibility to older version, but in this case i think it's the most viable for the future.

for ZeroFill's case, boots built a flexible timer as modifier (instead of block), that should work across files, right?

if it's really needed anywhere else (although it's really bad style IMHO) such blocks can be tricked by registering "block" and "/block" as two distinct simple functions. one does "ob_start()", the other does "ob_get_contents()" and both call their corresponding "old" block-function. it's just not easy to make auto-loadable.

boots · Posted: Mon Nov 17, 2003 4:02 pm Post subject:

Just to make sure I was clear--the "feature" I refered to that I'm +1 for dropping is the wonky block handling as messju more explicitly defined in his last post. As long as you don't cross file boundaries, the original {timeblock} still works, but as messju kindly said, my other timer approach is more flexible -- it even works between template and php code.

More to the point, I am very much behind the idea of being "correct" rather than BC for syntax issues in Smarty. Never-the-less, BC issues are probably best broken with major versions. In the case of the change of block functions I am little concerned as there are nearly always things that can be done to the template to restore the needed balance of tags and I suspect that only rare cases will be broken.

Considering that the block change was made in the cvs very shortly after the 2.5.0 release, I think it has probably been well shaken out by now. I *really* hope this was the only broken case Smile