| View previous topic :: View next topic |
| Author |
Message |
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
 Posted: Sat Apr 10, 2010 12:55 pm Post subject: What's happened with {if ... } ? |
 |
|
Something is wrong with {if ... } tag.
Of course I understand the qoute from README:
| Quote: | *) Delimiters surrounded by whitespace are no longer treated as Smarty tags.
Therefore, { foo } will not compile as a tag, you must use {foo}. This change
Makes Javascript/CSS easier to work with, eliminating the need for {literal}.
This can be disabled by setting $smarty->auto_literal = false;
|
I sure Smarty3 should understand the difference between: (to get that as just no smarty tag) and (to get that as smarty {if} construction). The recent has to be understanding as
Bug? |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Sat Apr 10, 2010 2:27 pm Post subject: |
|
|
It is a Smarty 3 feature that these:
are ignored (ie. javscript/css), whereas this:
is recognized as a tag. Smarty is not going to decide mixtures of the two, the syntax is absolute. If you don't like it, turn off the auto_literal (back to Smarty 2 behavior.) |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Sun Apr 11, 2010 3:36 am Post subject: That's the thing! |
|
|
| mohrt wrote: | | Smarty is not going to decide mixtures of the two, the syntax is absolute. If you don't like it, turn off the auto_literal (back to Smarty 2 behavior.) |
Of course I've accepted it clearly. But I think if there is no space between left brace and tag name (like {if or {foreach) Smarty should find the appropriate right either there is space before it or not.
It is obviously, is not it? I hope the most thinks such. Thanks. |
|
| Back to top |
|
U.Tews
Administrator
Joined: 22 Nov 2006
Posts: 5068
Location: Hamburg / Germany
|
| Posted: Sun Apr 11, 2010 1:59 pm Post subject: |
|
|
With auto_literal= true
is invalid. It's not a bug. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Mon Apr 12, 2010 3:04 am Post subject: |
|
|
| It isn't obvious, because contexts can be mixed. Smarty understands that spaces around tags are to be ignored, and if you mix them, Smarty isn't going to guess at what was meant to be Smarty tag and what wasn't. |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Mon Apr 12, 2010 6:31 am Post subject: |
|
|
| mohrt wrote: | | Smarty understands that spaces around tags are to be ignored, and if you mix them, Smarty isn't going to guess at what was meant to be Smarty tag and what wasn't. |
Since the first post I try to focus Smarty3 just have to guess and notice such tags (left brace without space and appropriate right brace with possible space). Smarty3 have to consider that as usual tag. Let us make developer survey? You make the product for consumers not for self, don't you? |
|
| Back to top |
|
emt
Smarty Regular
Joined: 10 Dec 2009
Posts: 43
|
| Posted: Mon Apr 12, 2010 8:15 am Post subject: |
|
|
I agree with the Developers - they have established a syntax and it is up to us to follow the syntax, just like we do with any programming language.
I really don't want to have the code bloated by algorithms to try to guess what I mean - and if I truly want there to be a space before the curly brace I don't want the Smarty compiler to guess that I got it wrong, and change it for me! |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Mon Apr 12, 2010 8:51 am Post subject: |
|
|
It is like you don't understand what I mean. Here is an example gives me the think:
| Code: | {if
$Spreadsheet->ObjectTotalQt>1
&&
!$Spreadsheet->SetFilterQt
&&
($Object.$FIELD_TOP && $Spreadsheet->TopDegree || !$Object.$FIELD_TOP && $Spreadsheet->Degree || $Spreadsheet->UseToggle)
} |
The example worked right before S3 update. And now I must set the right brace just after last bracket of condition. So I can't visually embrace where the condition is finished because it ends out of screen. I have to scroll to find the end. The question is the innovation is useless and even harmful in this case, is not it? Don't say I try to off auto_literal because I use it for JS and CSS. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Mon Apr 12, 2010 2:47 pm Post subject: |
|
|
| TTA wrote: | It is like you don't understand what I mean. Here is an example gives me the think:
| Code: | {if
$Spreadsheet->ObjectTotalQt>1
&&
!$Spreadsheet->SetFilterQt
&&
($Object.$FIELD_TOP && $Spreadsheet->TopDegree || !$Object.$FIELD_TOP && $Spreadsheet->Degree || $Spreadsheet->UseToggle)
} |
The example worked right before S3 update. And now I must set the right brace just after last bracket of condition. So I can't visually embrace where the condition is finished because it ends out of screen. I have to scroll to find the end. The question is the innovation is useless and even harmful in this case, is not it? Don't say I try to off auto_literal because I use it for JS and CSS. |
What you are demonstrating here is an ambiguity in syntax, because the closing tag syntax of a CSS/JS block is identical. Smarty will not try to decide what context you are in on the closing tag. It's not about coding for the customer, it's about a logistical problem that works best if we keep the syntax absolute. When Smarty encouters the "}" tag, it does not know if it is inside the context of the IF block or not. Even if we did go to the trouble of making the compiler work that way, imagine the debugging confusion if you left a closing brace off of a smarty tag or CSS block, and the compiler picked up another one further down the page for it.
Smarty needs to know what each { and } is for in the template, either a Smarty tag, or non-Smarty tag, and the identification method is by inspecting the adjacent white space. If you don't like that, turn off auto-literal and escape the JS/CSS yourself.
And (somewhat OT) You are demonstrating some complicated IF (business) logic that could be consolidated into a plugin or modifier to keep the template syntax lighter, ie. {if $Spreadsheet|ss_show} OR, do that calculation php-side and assign a simple flag, such as {if $show_spreadsheet}. This keeps the template (view) squarely focused on the task at hand, and not the business logic it took to get there. |
|
| Back to top |
|
Lemon Juice
Smarty Pro
Joined: 24 May 2006
Posts: 109
|
| Posted: Mon Apr 12, 2010 3:37 pm Post subject: |
|
|
| TTA wrote: | | Code: | {if
$Spreadsheet->ObjectTotalQt>1
&&
!$Spreadsheet->SetFilterQt
&&
($Object.$FIELD_TOP && $Spreadsheet->TopDegree || !$Object.$FIELD_TOP && $Spreadsheet->Degree || $Spreadsheet->UseToggle)
} |
The example worked right before S3 update. And now I must set the right |
I imagine that in normal html page flow this would not cause any problems but if the block were placed within a css or js section then things would get complicated, while theoretically this is doable for the parser it could end up in a mess and debugging confusion for people. Probably the best solution is to keep it strict like the devs say. If you can't live with it you can create a prefilter that will strip the space before the closing brace in such cases.
BTW, are you using an editor without a word wrap feature? |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Mon Apr 12, 2010 4:45 pm Post subject: |
|
|
| mohrt wrote: | | And (somewhat OT) You are demonstrating some complicated IF (business) logic that could be consolidated into a plugin or modifier to keep the template syntax lighter, ie. {if $Spreadsheet|ss_show} OR, do that calculation php-side and assign a simple flag, such as {if $show_spreadsheet}. This keeps the template (view) squarely focused on the task at hand, and not the business logic it took to get there. |
Indeed! This idea has a right to exist -- a modifier. Honestly I confuse by need of my own modifier location "/libs/plugins/". I'd like to bring it out to another dir. Is it possible? Thanks before. But I have not found something in the manual.
In any case it's the best context solution. I've just thought about situation:
| Code: | | div.main { color: {if ***}red{else}blue{/if} } |
And you are right.
| Lemon Juice wrote: | | BTW, are you using an editor without a word wrap feature? |
Of course it exists. My experience says it's not used by me often  It's not so easy to find the brace quickly:
| Code: | | $Spreadsheet->UseToggle)} |
|
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Mon Apr 12, 2010 4:54 pm Post subject: |
|
|
| The $smarty->plugins_dir value can be an array of directories in case you want Smarty to search through multiple dirs and find the first match. So make your own plugins directory, and let Smarty look there first, and then into its own. |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Mon Apr 12, 2010 5:59 pm Post subject: |
|
|
| mohrt wrote: | | The $smarty->plugins_dir value can be an array of directories in case you want Smarty to search through multiple dirs and find the first match. So make your own plugins directory, and let Smarty look there first, and then into its own. |
Oh! Greate thanks! |
|
| Back to top |
|
TTA
Smarty Rookie
Joined: 10 Apr 2010
Posts: 17
Location: Ukraine, Kiev
|
| Posted: Mon Apr 12, 2010 6:31 pm Post subject: |
|
|
| mohrt wrote: | | The $smarty->plugins_dir value can be an array of directories in case you want Smarty to search through multiple dirs and find the first match. So make your own plugins directory, and let Smarty look there first, and then into its own. |
Unfortunately I've caught the another. So see there: http://www.smarty.net/forums/viewtopic.php?p=63901#63901 |
|
| Back to top |
|
douglassdavis
Smarty Junkie
Joined: 21 Jan 2008
Posts: 541
|
| Posted: Mon Apr 12, 2010 8:01 pm Post subject: |
|
|
| mohrt wrote: | | TTA wrote: | It is like you don't understand what I mean. Here is an example gives me the think:
| Code: | {if
$Spreadsheet->ObjectTotalQt>1
&&
!$Spreadsheet->SetFilterQt
&&
($Object.$FIELD_TOP && $Spreadsheet->TopDegree || !$Object.$FIELD_TOP && $Spreadsheet->Degree || $Spreadsheet->UseToggle)
} |
The example worked right before S3 update. And now I must set the right brace just after last bracket of condition. So I can't visually embrace where the condition is finished because it ends out of screen. I have to scroll to find the end. The question is the innovation is useless and even harmful in this case, is not it? Don't say I try to off auto_literal because I use it for JS and CSS. |
What you are demonstrating here is an ambiguity in syntax, because the closing tag syntax of a CSS/JS block is identical. Smarty will not try to decide what context you are in on the closing tag. It's not about coding for the customer, it's about a logistical problem that works best if we keep the syntax absolute. When Smarty encouters the "}" tag, it does not know if it is inside the context of the IF block or not. Even if we did go to the trouble of making the compiler work that way, imagine the debugging confusion if you left a closing brace off of a smarty tag or CSS block, and the compiler picked up another one further down the page for it.
Smarty needs to know what each { and } is for in the template, either a Smarty tag, or non-Smarty tag, and the identification method is by inspecting the adjacent white space. If you don't like that, turn off auto-literal and escape the JS/CSS yourself.
And (somewhat OT) You are demonstrating some complicated IF (business) logic that could be consolidated into a plugin or modifier to keep the template syntax lighter, ie. {if $Spreadsheet|ss_show} OR, do that calculation php-side and assign a simple flag, such as {if $show_spreadsheet}. This keeps the template (view) squarely focused on the task at hand, and not the business logic it took to get there. |
In my humble opinion, the } should be allowed to be separated by non-linebreak spaces. much easier to read and no debugging confusion best of both worlds.  |
|
| Back to top |
|
|
