smd_if: Generic multiple if condition tests

Bloke · 2009-03-22 19:50:15

gomedia wrote:

Now that we’re all doing lovely tags within tags, there’s an increased danger of whitespace creeping in where you don’t expect it.

Glad you’re finding the plugin useful. There’s a kind of undocumented solution to the spaces thing (err, I think). If you are expecting a value (or a field) that may have spaces in it, add :NOTAGS to the variable (e.g. txpvar:x:NOTAGS). That strips out PHP and HTML tags from the string and also performs a trim() to remove whitespace (because often simply removing tags leaves extraneous whitespace lying around).

If it helps any — and you can perhaps see a situation when you may need to trim extraneous spaces without stripping PHP/HTML tags — I could add a dedicated TRIM modifier to the next version? Currently, the NOSPACE modifier could be (mis)used if you like, but since it only works on fields you’d have to switch your value/field attributes over which may or may not yield the desired true/false result from the plugin.

Let me know if you think a TRIM modifier would help (and any other modifiers you might consider useful — I could add them all at once).

Last edited by Bloke (2009-03-22 19:50:51)

gomedia · 2009-03-22 20:57:00

Bloke wrote:

Let me know if you think a TRIM modifier would help …

Thanks Stef, I think it would be a useful safety harness. And it would mean that we could keep some semblance of readability in the source code – so instead of:

<txp:variable name="height" value='<txp:upm_article_image><txp:upm_img_full_height /></txp:upm_article_image>' />

We could do:

<txp:variable name="height" value='
  <txp:upm_article_image>
    <txp:upm_img_full_height />
  </txp:upm_article_image>
'/>

and not have to worry about blanks/tabs/newlines etc.

Cheers,

Adi

Bloke · 2009-03-22 21:28:13

Consider it done in v0.77 | compressed.

gomedia · 2009-03-22 21:47:53

Stef,

Blimey, you’re quick off the mark. Thanks.

Too quick for me! I’d just sat down to send you another suggestion: a trim="1" attribute, to save having to use a modifier in both field & value.

All the best,

Adi

Bloke · 2009-03-22 22:37:21

gomedia wrote:

a trim="1" attribute

I didn’t do it that way in case you only wanted to apply it to one particular test — it’s more granular when comparing multiple, disparate things. But offering the option to globally apply it makes sense so I’ll do that as well to save you the hassle if you need to trim all fields+values in all tests.

What I might actually do is offer a modifier attribute, where you can choose which modifiers to apply across the board. e.g. modifier="TRIM, NUM" would trim all fields and values in all tests, and make sure any numeric-based operations were treated as numbers instead of strings. In theory I think it’ll work; need to think it through to check it’s feasible and you can’t inadvertently create some paradox that defies the space-time continuum.

Not tonight though. Eyes closing…

rathersplendid · 2009-03-26 12:45:45

Hey Stef, or anyone else who maybe able to help out,

I’m looking to, hopefully, use this plugin to create a conditional to work out the current month/date/time and change the page’s body class based on the result. What I want to do is use this to the change the page layout using CSS. Do you see what I mean?

Do you think this can be done? And if so, how?? My PHP is not pretty poor…

Thanks in advance guys.

Bloke · 2009-03-26 13:08:34

rathersplendid wrote:

create a conditional to work out the current month/date/time and change the page’s body class based on the result.

It kind of depends how clever you want to be. Are you going to want to read the date from anywhere, like the URL? (e.g. site.com/2009/03/26?) Or do you just care about changing the look based on “now” (and is “now” the user’s “now” or the server’s “now” because it may make a difference?)

smd_calendar has some supoprt for getting today’s date through the <txp:smd_cal_now /> tag but it’s probably less hassle to do something directly, like this:

<txp:variable name="theDay" value='<txp:php>echo strftime("%d");</txp:php>' />
<txp:variable name="theMonth" value='<txp:php>echo strftime("%m");</txp:php>' />
<txp:variable name="theYear" value='<txp:php>echo strftime("%Y");</txp:php>' />
<txp:variable name="theTime" value='<txp:php>echo strftime("%T");</txp:php>' />

and then use smd_if with txpvar: to do some basic checking like is theMonth > 6 and so on. Look at strftime for some ideas of how you can use it to get at the current bits of the current date/time to build your own output.

rathersplendid · 2009-03-26 13:13:22

Stef, it needs to be now, and it doesn’t really matter for me about server time or user time because, for the moment at least, I only need to change the style by month.

I will have a look at what you suggested and get back to you; from the looks of it, I should be able to manage it now.

Cheers mate

maniqui · 2009-04-04 23:05:10

Hi Bloke,
For testing purposes, I’ve wrote this code:

<txp:smd_if logic="OR" field="urlvar:jquery" operator="eq,eq,eq" value="1.2.6,1.3.1,1.3.2">
  <script src="/js/jquery-{smd_if_jquery}.min.js" type="text/javascript"></script>
  <txp:else />
  <script src="/js/jquery-1.2.6.min.js" type="text/javascript"></script>
</txp:smd_if>

Wonder if it makes senses to have some kind of “default” (fallback) value for undefined and similar operators.
So, to have the ability to write something like this:

<txp:smd_if logic="OR" field="urlvar:jquery" operator="eq,eq,eq,undefined" value="1.2.6,1.3.1,1.3.2,1.2.6">
  <script src="/js/jquery-{smd_if_jquery}.min.js" type="text/javascript"></script>
</txp:smd_if>

There, the fallback value for undefined is the latest 1.2.6.

Last edited by maniqui (2009-04-04 23:11:12)

maniqui · 2009-04-04 23:14:52

BTW, the help docs says:

Note that, although the first three attributes are considered mandatory, if you happen to require the default operator for all your tests, you can safely omit operator.

I’ve tried (no explicit operator attribute):

<txp:smd_if logic="OR" field="urlvar:jquery" value="1.2.6,1.3.1,1.3.2">
  <script src="/js/jquery-{smd_if_jquery}.min.js" type="text/javascript"></script>
  <txp:else />
  <script src="/js/jquery-1.2.6.min.js" type="text/javascript"></script>
</txp:smd_if>

But it always seem to enter the txp:else branch.

Bloke · 2009-04-04 23:15:40

maniqui wrote:

Wonder if it makes senses to have some kind of “default” (fallback) value

Interesting. I put this concept in smd_query so I guess there’s no reason it can’t migrate its way across here too.

Let me have a think about how to do it and see if I can make it work in some reasonable (and extensible, semi-logical) fashion for relevant operators. Thanks for the idea.

Bloke · 2009-04-04 23:39:28

maniqui wrote:

<txp:smd_if logic="OR" field="urlvar:jquery" value="1.2.6,1.3.1,1.3.2">

Right, the docs are slightly misleading here *ahem*. The short-circuit system is actually only based on the field and operator not value. It only checks the number of items in the greater of either field or operator. So in your case, you have 1 field and 1 (default) operator, so it only checks 1 value. If you had:

<txp:smd_if logic="OR" field="urlvar:jquery" operator="gt, lt" value="1.2.6,1.3.1,1.3.2">

it would check ‘jquery’ against the first two values (because there are two operators). If you had:

<txp:smd_if logic="OR" field="urlvar:jquery, urlvar:othervar" operator="gt" value="1.2.6,1.3.1,1.3.2">

it would check if ‘jquery’ is greater than 1.2.6 and if ‘othervar’ is greater than 1.3.1 and then stop. So the value attribute is really a 2nd class citizen; the number of tests performed are only as great as the number of operators or fields. I couldn’t find a very good way of explaining that in the docs, but perhaps I should come up with something!

I did try and make it work so you could short circuit values too — as you expect, here — but it kept giving me runtime errors due to missing content, so I gave up. Perhaps I’ll find a way one day.

Oh, and incidentally, could you do this instead to simplify things:

<txp:smd_if field="urlvar:jquery" operator="in" value="1.2.6/1.3.1/1.3.2">
...

Textpattern CMS

Textpattern CMS support forum

#217 2009-03-22 19:50:15

Re: smd_if: Generic multiple if condition tests

#218 2009-03-22 20:57:00

Re: smd_if: Generic multiple if condition tests

#219 2009-03-22 21:28:13

Re: smd_if: Generic multiple if condition tests

#220 2009-03-22 21:47:53

Re: smd_if: Generic multiple if condition tests

#221 2009-03-22 22:37:21

Re: smd_if: Generic multiple if condition tests

#222 2009-03-26 12:45:45

Re: smd_if: Generic multiple if condition tests

#223 2009-03-26 13:08:34

Re: smd_if: Generic multiple if condition tests

#224 2009-03-26 13:13:22

Re: smd_if: Generic multiple if condition tests

#225 2009-04-04 23:05:10

Re: smd_if: Generic multiple if condition tests

#226 2009-04-04 23:14:52

Re: smd_if: Generic multiple if condition tests

#227 2009-04-04 23:15:40

Re: smd_if: Generic multiple if condition tests

#228 2009-04-04 23:39:28

Re: smd_if: Generic multiple if condition tests

Board footer