Thread

Sorry, Kevin.  Can you give the full context, i.e. a complete code sample, including any tags?

Ok, I understand now.  I also reread your reply above (#2) and that cleared things up:

As the code executes, a more accurate description really is any conditional that is comprised of multiple comparison operations or variables that are not “whitelisted” (that the template parser knows about and knows for a fact when they are available) will be parsed as an “advanced” conditional.

I was under the impression that the simple/advanced separation was more of a “feature” design, rather than a performance issue.

In my opinion the documentation for conditionals and parse order needs to be re-written and expanded. Maybe with a big red flashing marquee that says “DON’T PUT HEAVY CODE INSIDE OF ADVANCED CONDITIONALS!”

Aaron

Sorry, Kevin.  Can you give the full context, i.e. a complete code sample, including any tags?

Sure, here’s a fairly complete template that provides an example of the problem. Now what’s strange is that if the first conditional to determine if segment_3 is ‘edit’ returns false, the rEEdirect plugin (unreleased to the public) apparently does not run, but the String plugin still prepends and appends as you’d expect if the conditional were eval’d true. In short, that means that all the String tags in the template are being processed regardless of the conditionals. I was hoping to use the String plugin to dynamically alter the title and breadcrumbs based on segment values.

{exp:string:set name="my_channel"}members{/exp:string:set}
{exp:string:set name="my_template_group"}members{/exp:string:set}
{exp:string:set name="page_id"}profile{/exp:string:set}
{exp:string:set name="title"}// {site_name} - {slogan}{/exp:string:set}
{exp:string:set name="breadcrumbs"}<a href="http://{path=members}">My Home</a>{/exp:string:set}
{exp:string:append name="breadcrumbs" separator="»" glue="SPACE"}<a href="http://{path=members/list}">Members</a>{/exp:string:append}

{embed="site/_header"}
<div id="inner_wrapper">

<div id="content">
    
    {if segment_3 == 'edit'}
        {exp:reedirect if="logged_out" location="members/login" method="script"}
        {exp:string:prepend name="title" separator="" glue="SPACE"}Edit My Profile{/exp:string:prepend}
        {exp:string:append name="breadcrumbs" separator="»" glue="SPACE"}Edit My Profile{/exp:string:append}
    {/if}    
    
    {if segment_3 != 'edit'}
    {exp:user:stats}

    {exp:string:prepend name="title" separator="" glue="SPACE"}{if logged_in && segment_3 == ''}My Profile{if:else}{screen_name}'s Profile{/if}{/exp:string:prepend}
    {exp:string:append name="breadcrumbs" separator="»" glue="SPACE"}{if logged_in && segment_3 == ''}My Profile{if:else}{screen_name}{/if}{/exp:string:append}

    (various content here…)

    {/exp:user:stats}
    {/if}

</div><!--/#content-->

</div><!--/#inner_wrapper-->
{embed="site/_footer"}

You have other conditionals inside the second segment conditional, including an {if:else} which tells the template parser “Whoa!  This one needs a closer look before we can assume what we’re replacing”, so the whole thing gets saved for advanced conditional parsing; again so it can be done only once, and not repeatedly for each special case that the parser encounters.  Stick those contents in an embedded template and you’ll be fine.

You have other conditionals inside the second segment conditional, including an {if:else} which tells the template parser “Whoa!  This one needs a closer look before we can assume what we’re replacing”, so the whole thing gets saved for advanced conditional parsing; again so it can be done only once, and not repeatedly for each special case that the parser encounters.  Stick those contents in an embedded template and you’ll be fine.

Ah… makes sense then. Thanks for the look!

Also, just for the benefit of anyone reading this thread, I’m unable to use embedded templates in my situation because I’m using the String plugin. The way EE templates are parsed, I can use String in the main template and it’ll carry over into the embedded template, but not the other way around. Looks like I’ll be using separate templates in this case instead of a single template with segment conditionals.

You may want to take a look at Switchee. I use this instead of if:else wherever I can - particularly where I want to use asingle template to do multiple things (index list with pagination, and single entry). Also, Mark took a crack at writing a “better” if:else today, which you can see on Github: Ifelse

You might also read this thread in Switchee support at devot:ee If’s as well as Switch

Awesome, I’ll look at both tomorrow. Now that you’ve mentioned another plugin, it has me thinking… what order does EE parse plugins/modules? Alphabetically? Or in the order they’re used in the template?

As far as I can tell, the choice has been made based on performance reasons - not what would’ve worked best from a developer perspective. That’s fair enough, although it’s a bit of a PITA the way it is now. I think other options should be explored;

1) In most real-life use cases, will it be faster to parse everything as opposed to evaluating the “advanced conditionals”? Just asking. My experience is that this leads to a lot of overhead - a bunch of modules are run when they don’t really have to. It can’t always be fixed with the embed trick.

2) If 1) really is the case, that it is in fact very slow to parse these advanced conditionals; how about parsing them on template save and then saving the template as PHP instead? Yes, this is complicated. But would it be possible? Again, just asking.

Anyway, I think EE would hugely benefit from having a template system with conditionals that were:

1. Consistent
2. Predictable

I’m sure it is that for the developers behind it. However, to many of us it isn’t.

how about parsing them on template save and then saving the template as PHP instead? Yes, this is complicated. But would it be possible? Again, just asking.

What do you mean by “on template save” ? Do you mean when I save the template in the CP it pares advanced conditionals? Or are you maybe talking about saving cached versions of templates?

Just curious 😊

Forget the “on template save” .. it could be saved parsed and “cached” at any time, most likely not on template save at all, heh, but doesn’t really matter much. I do know other template engines (Smarty, Twig) do this - but I’m pretty sure this would not translate directly to EE as there are a lot of stuff to consider (esp. addons). To quote Facebook; It’s complicated.

I see Devot:ee has a use-case for us 😉

http://twitter.com/#!/devot_ee/status/27941095788
http://twitter.com/#!/devot_ee/status/27941976340

One quick thought. On templates you want to test to see if a conditional is simple or complex, turn php on output and put <?php die(‘Advanced Conditional’);?> inside the tag that you don’t want to load. (ie, on a list page and single entry page, put it on the listing part and go to the single entry page and see if the page loads fine)