Could be - try passing {member_group} as a variable to the embedded template, and referencing as {embed:member_group}

Just tried it and it’s not working - my guess is it’s a parsing order issue as the default condition is displaying in each case…

You’re right, member_group must be parsed later by EE.

If you enable php at input stage for your template you could do it like this:

... which actually gives me an idea. Would people be interested in having the ability to specify a variable from the various globals arrays and have switchee grab it? 

eg [sess_username] or [post_member_id] or [get_id] or [cookie_year] etc

What do you think?

Mark, your PHP solution worked, thanks - but in that embedded template I have some other PHP code that must be parsed on output…alas.

But not a huge deal, just looking for ways to optimize speed on some templates that are using a fair number of conditionals.

The alternative would be to write a small plugin and wrap switchee with it.

and then:

The plugin route worked (!) now I need to see how much of a performance improvement it makes…

Mark,

I’m using your plugin and finding that my “no_results” weblog checks are not working properly.  Is this because of the parsing order?  Can you think of a way around this?

In the above code the “no results” conditional does not work if the parse=“inward” parameter is set on the switchee plugin

Piping up: will this be ported to EE2?

Hi Mark,

I did some hacking with Switchee plugin:

1) I added “excise” parameter.

“excise” parameter accepts two values - “max” (default) and “min”. It allows you to specify if
tagdata which surrounds matched case should be outputted (min) or not (max). E.g. in case
{variable_to_test} has as its value the value1 the code

will output

AAAAAAAAA

But the code

in case {variable_to_test} has as its value the value1 will output

blah blah blah
AAAAAAAAA
blah blah blah
blah blah blah

2) It is not possible to nest plugin tags. In order to circumvent tthis limitation I created the clone of Switchee plugin - Switchee2. Using Switchee and Switchee2 it is possible to write the code as this:

If you like my additions, feel free to incorporate them into official version.

Hmm I seem to have been unsubscribed from this thread for some reason. Sorry all for not replying sooner.

@Joe Wolin
If you put {exp:weblog:entries} tag in an embedded template then your no_results tag will work as expected.

@Royal Glenora Club
Just as soon as I do a job with EE2 I’ll port it. Should be dead simple.

@Laisvunas
Those are very interesting additions. The ‘excise’ parameter is very neat indeed, I think I’ll add that to the ‘official’ version

Nesting - it seems somewhat unelegant to have to clone the plugin to get nesting, so I’m not sure about that one. It does suggest another solution - parsing the tag data and inserting aliases for nested tags, then parsing the aliases recursively. I’m going to have a think about it a bit.

Hi Mark,

I’m glad that you liked my addition of “excise” parameter.

Nesting - it seems somewhat unelegant to have to clone the plugin to get nesting, so I’m not sure about that one. It does suggest another solution - parsing the tag data and inserting aliases for nested tags, then parsing the aliases recursively. I’m going to have a think about it a bit.

Creating a clone of the plugin was quick and dirty solution for enabling to nest {case}{/case} variable pairs. Of course, it would be much better if it were possible to nest them inside the same plugin tag.

BTW, in plugin Find and Replace Plus it is possible to nest {replace_area}{/replace_area} variable pairs.

@Mark,

Can you think of any other way to process a no_results type output without resorting to an embed?  I’m trying to stay clear of embeds to achieve the best performance as I’ve ready it can add a lot of overhead.

thanks…

Mark, this looks awesome, I can definitely think of several spots I can use it.  But it won’t quite do the trick for the coding issue that made me start looking for something like this in the first place - let me explain.

I’m an old mainframe coder - in Cobol, we have an instruction set that’s similar to switch-case-default, called EVALUATE.  It works like this:

EVALUATE (VARIABLE-NAME)
  WHEN (‘1’)
      code to execute…
  WHEN (‘2’)
      code to execute…
  .
  .
  .
  WHEN OTHER
      default code
END-EVALUATE.

However, it has one very important difference - it allows me to evaluate the reserved word TRUE, and then check the value of various switches and variables in the WHEN clauses, like this:

EVALUATE TRUE
  WHEN (SWITCH-1 = ‘Y’ AND SWITCH-2=‘Y’ AND STATE = ‘MA’)
      code to execute…
  WHEN (SWITCH-1 = ‘Y’ AND SWITCH-2=‘Y’ AND STATE NOT = ‘MA’)
      code to execute…
  .
  .
  .
  WHEN OTHER
      default code
END-EVALUATE.

The first WHEN clause that returns TRUE gets executed - if none of them return true, the default code gets executed.  Can you see any way to make switchee do that?  I think it would remove the need for nesting, and be really, really handy.  Let me know what you think, thanks!

Hi John

that’s very interesting. I think it could be possible to add this but what worries me is the AND/OR/NOT logic between evaluated conditions. Currently Switchee effectively only supports OR (using the pipe | separator). Parsing the case values to evaluate the sum of these conditions would be tricky. Having said that, that’s what EE’s if/else advanced conditionals do so there may be code I can borrow there. I’ll look into it.

By the way, if you or anyone else reading this would like to help improve Switchee, I’m now hosting it on Github. Please fork and I’ll happily pull any changes that work well.