smd_if: Generic multiple if condition tests

NeilA · 2008-01-06 19:07:34

Bloke wrote:

Try v0.4 (or the compressed version) with the official question-mark-in-value extension/patch mentioned above and more robust quote support. Shout if anything goes sideways, and thanks again for finding the bugs.

You’re a legend Stef! v0.4 seems to be working fine. Thanks so much…

Cheers

Last edited by NeilA (2008-01-06 19:58:19)

peterj · 2008-01-06 21:10:40

Stef, v 0.4.1 is working perfectly, thank you.

the_ghost · 2008-01-13 13:29:23

Something is wrong.

For ex. i have the following category structure:

metro
1. metro1
2. metro2
3. metro3

My code:

<txp:smd_if field="parent" value="metro">
	the list of metro stations <txp:category title="1" />
</txp:smd_if>

And if we are at global category metro1 (url looks like http://uromax.ru/category/metro1) plugin should return true, but:

<txp:smd_if field="parent" value="metro">
[SQL (0,000463): select lft as l, rgt as r from uro_txp_category as txp_category where name='avtozavodskaya' and type = 'article']
[SQL (0,000469): select * from uro_txp_category as txp_category where lft <= 21 and rgt >= 22 and type = 'article' order by lft asc]
[<txp:smd_if field="parent" value="metro">: false]
</txp:smd_if>

At the same time i have another plugin nfe_if_category:

<txp:nfe_if_category parent="METRO">
</txp:nfe_if_category>

And it works fine at the same page:

<txp:nfe_if_category parent="METRO">
[SQL (0,027634): select lft, rgt from uro_txp_category as txp_category where name = 'METRO']
[SQL (0,001715): select name, title from uro_txp_category as txp_category where (lft between 2 and 309) and type = 'article' and name != 'default'  order by lft asc]
[<txp:nfe_if_category parent="METRO">: true]

Some information:

the whole tagtrace is here
Diagnostic is here

Last edited by the_ghost (2008-01-13 13:38:47)

Bloke · 2008-01-13 15:10:49

Thanks for the detailed diagnostics, the_ghost. I originally thought this had something to do with the URL structure (using /category/metro1 instead of ?c=metro1) but I tried a similar setup on my server and it worked fine. Out of curiosity, does it work if you use:

http://uromax.ru/?c=metro1

I don’t think it’ll make any difference, but I’d like to find out.

The next puzzling thing is that the plugin thinks the name you supplied in the value parameter is “avtozavodskaya” instead of “metro1”. Any idea where “avtozavodskaya” comes from? Is it the name of a section or an article or something? Do your categories have a different name and title? (the plugin uses the name)

Can you try a couple of things please and post the results:

add debug="1" to the smd_if call. The plugin will output the whole category tree it tries to match, and a few other variables that might help me track the problem down
add <txp:php>global $pretext; dmp($pretext);</txp:php> somewhere near the smd_if call and tell me what it outputs

If you’d rather not post these values publicly you can email them to me instead or use the forum e-mail system.

Sorry it’s not working: I can’t see what the problem is at the moment but clearly it should work so I’ll keep poking at the code and see if anything leaps out at me.

Last edited by Bloke (2008-01-13 15:11:17)

the_ghost · 2008-01-13 16:31:46

metro1 was provided like example to make my example clear. Аctually ш have the following tree of categories:

metro
- http://uromax.ru/category/AVIAMOTORNAYA
- http://uromax.ru/category/BRATISLAVSKAYA
- and so on…

And i have glossary were childs are the letters:

slovar (russian translation of glossary)
- http://uromax.ru/category/A/
- http://uromax.ru/category/B/
- http://uromax.ru/category/V/
- and so on…

The result of debugging you can currently see:

Link to child of metro – uromax.ru
Link to letter of glossary (parent is slovar) – uromax.ru

Bloke · 2008-01-13 17:36:30

Aha, right, I think it might be a conceptual difficulty with the way I implemented the parent option. I will revisit the help to try and make it clearer, sorry!

First, a few observations:

None of your examples contain an operator parameter, therefore they default to always compare exact equality (eq).
The searches are always case sensitive (looking at this again, I will actually go back and add a parameter to allow you to turn this off in the next revision of the plugin)
Usually with the parent option you would use operator="contains" or operator="begins" , and here is why:

Unlike nfe_if_category, the parent parameter does not directly compare just the “top level” parent with the value you supply. What it does is look at the entire tree from the current category all the way “up” to the root. Internally, the plugin concatenates that hierarchy into one long string and compares against that.

So if you had categories:

metro (level 1)
- AVIAMOTORNAYA (level 2)
- BRATISLAVSKAYA (level 2)
  - INFO (level3)
- DUBROVKA (level2)

And you were currently browsing the ‘INFO’ category, its parents would be both “metro” and “BRATISLAVSKAYA”. By default, the plugin makes this into one string like this “metro BRATISLAVSKAYA” and tests for a match against that.

Thus, to see if the current category is a descendent of metro you could use:

<txp:smd_if field="parent" operator="begins" value="metro">
  //something
</txp:smd_if>

Now, in your case, this is too general and you probably want to see if the current category is somewhere below the ‘level 1’ category called ‘metro’. The parent field can be told to only look at a particular tree level by adding the LVL modifier to the end. e.g.

<txp:smd_if field="parent:LVL1" value="metro">
  //something
</txp:smd_if>

Notice now you may omit the operator parameter because you are always directly comparing (eq) the value to a single category level which can of course only contain one element.

btw, in your second case you would have to use value="SLOVAR" because your category name is in capital letters. I will fix that in the next revision by adding a case_sensitive attribute.

Sorry if all that sounds confusing but I thought it was the most flexible solution. And sorry that the documentation neglects to mention this adequately! I will also fix the help with better examples and make it obvious that by default you should use contains or begins with the parent, but adding a :LVL allows you to use eq.

Does that (sort of) make sense? If you can think of a better way of implementing it without sacrificing the ability to search the whole tree, then please let me know :-)

Last edited by Bloke (2008-01-13 17:40:25)

the_ghost · 2008-01-13 18:18:38

Yes. It works now :)

I think you should make operator="contains" default for checking parent category.

And you know, I use mostly logic="or", so I prefer it to be default value. But i think i can modify plugin for this. I mentioned this because maybe most users like “or” action?

Bloke · 2008-01-13 18:37:53

the_ghost wrote:

Yes. It works now :)

Excellent!

I think you should make operator="contains" default for checking parent category.

Good idea. I’ll look into doing that.

maybe most users like “or” action?

Personally I use AND more than OR with this plugin but if any other people agree with the_ghost that OR makes a more sensible default I can certainly change it. Anyone?

the_ghost · 2008-01-13 18:54:53

P.S. I think it would be pleasant to perform all manipulations after lowercasing checking values.

Bloke · 2008-01-14 11:03:58

Version 0.5 is out (compressed) that takes into account most of the features requested by the_ghost:

Default operator for parent is now contains (it is eq for everything else)
New attribute: case_sensitive. 0=ignore case; 1=case-sensitive. NOTE that all comparisons now ignore case by default
New attribute: param_delim. Allows you to override the comma when specifying lists (useful if you have a comma in the name of one of your custom fields or you just plain hate commas!)
New attribute: mod_delim. Allows you to override the colon when specifying field and parameter modifiers (like urlvar:varname or gt:NUM)
Improved the help to (hopefully) make the ‘parent’ explanation clearer; fixed some late-night typos

Many thanks to the_ghost for highlighting these modifications. I have NOT yet changed the default logic to OR. I will wait for a consensus on that before I forge ahead and do it, but in the meantime if it really bothers anyone to specify logic="or" in every smd_if call, modify line 8 of the plugin and change the ‘and’ to ‘or’.

EDIT: arghhhh! defined and undefined are brain damaged in this version and give an error. I’ve found an easy fix but I’ve decided I want to make the distinction between defined/isused and undefined/isempty a little wider so they become more useful. I’m hacking the code to do that before releasing the fix so for now please avoid defined and undefined as operators. Apologies.

Last edited by Bloke (2008-01-15 00:34:41)

the_ghost · 2008-01-15 00:38:10

If i understand correctly operator="or" or operator="and" is used for all checking statements? I mean:

<txp:smd_if field="parent,section,article_image" value="metro,about,2">
  something
</txp:smd_if>

This will output something only if parent contains metro AND section equal to about AND article_image equal to 2. This is nice, but what if we have to make coditional checking like this – I’ll write it in usual programming style, I think you will understand ;) :

if ( (parent=='metro' AND $section=='about) OR article_image==2) {
    echo "something";
}

The only problem – now i cannot imaging where this construction can be used… But if you like this idea we should think out how to group statements. It can be something like this:

<txp:smd_if field="parent,section,article_image" value="metro,about,2" and_group="1,2" or_group="3">
  something
</txp:smd_if>

This can help to make not very deep conditions (only 1 level as i see – like example’s deepness)

P.S. I thought over this method and it seems to be buggy :) I need some sleep to refill my imagination\inspiration tank.

Bloke · 2008-01-15 01:08:49

the_ghost wrote:

If i understand correctly operator="or" or operator="and" is used for all checking statements?

Yes, absolutely correct. To be honest I did consider being able to split the logic as you suggested because I knew someone would ask for it one day :-p

But when I originally did it I took the path of least resistance and just made it easy on myself. Now, your solution might work — I have not thought it through yet — but I wonder if just allowing the logic field to take a list of ANDs and ORs (with parentheses) might work? Of course, the complexity of the plugin goes up about 10 times because I then have to parse brackets and I am, in effect, partway towards writing a Reverse Polish calculator!

So something like :

<txp:smd_if field="parent, section, article_image" value="metro, about, 2" logic="(and), or">
  // something
</txp:smd_if>

What do you think??? You will always have one logic operator less than the number of comparisons.

The logic checking part of the plugin is currently very simple, done right at the very end. If I did it this new way I would have to parse the brackets, make up the replacement expressions as normal, plug them in the right places in the “logic” then probably execute the whole lot as one giant eval() statement. I may still be able to build it up in chunks (which I would prefer — easier on my brain and less likely to cause syntax errors from bogus options) but it’ll require some serious thought.

Of course, for backwards-compatibility if you specify a single “and” (or “or”) it will have to “expand” it and apply that to all the expressions; that bit’s easy.

I will have a think about it and see if it can be done. When you are feeling refreshed, if you come up with any cool way of doing it, please let me know…

Thanks!

Last edited by Bloke (2008-01-15 01:10:41)

Textpattern CMS

Textpattern CMS support forum

#25 2008-01-06 19:07:34

Re: smd_if: Generic multiple if condition tests

#26 2008-01-06 21:10:40

Re: smd_if: Generic multiple if condition tests

#27 2008-01-13 13:29:23

Re: smd_if: Generic multiple if condition tests

#28 2008-01-13 15:10:49

Re: smd_if: Generic multiple if condition tests

#29 2008-01-13 16:31:46

Re: smd_if: Generic multiple if condition tests

#30 2008-01-13 17:36:30

Re: smd_if: Generic multiple if condition tests

#31 2008-01-13 18:18:38

Re: smd_if: Generic multiple if condition tests

#32 2008-01-13 18:37:53

Re: smd_if: Generic multiple if condition tests

#33 2008-01-13 18:54:53

Re: smd_if: Generic multiple if condition tests

#34 2008-01-14 11:03:58

Re: smd_if: Generic multiple if condition tests

#35 2008-01-15 00:38:10

Re: smd_if: Generic multiple if condition tests

#36 2008-01-15 01:08:49

Re: smd_if: Generic multiple if condition tests

Board footer