[ic] if-sql-param question
Ethan Rowe
ethan at endpoint.com
Fri Jun 10 16:54:47 EDT 2005
JT Justman wrote:
>jeff at hisgirlfridays.com wrote:
>
>
>
>>Hello,
>>
>>I am using the following syntax and it is behaving oddly. Upon further
>>research, I am not even sure that if-sql-param can be used in this way:
>>
>>[if-sql-param food eq 'steak']
>> [tmp myscratch]bad[/tmp]
>> hello<br>
>>[/if-sql-param]
>>
>>The issue I am encountering is that sql-param food is not equal to
>>'steak', but myscratch is still being set to bad, however, "hello" is
>>never output. This is just plain weird to me and usually when ITL acts
>>weird it is because I am doing something syntactically incorrect.
>>
>>If this syntax is incorrect, what is the optimal way to perform this
>>comparison?
>>
>>
>>
>>
>>
>I don't see if-PREFIX-param in the docs. You could probably use
>something like:
>
> [if type=explicit compare="[sql-param food] =~ /steak/"]
> ...
>[/if]
>
>
On the contrary, [if-sql-param <some_column> <some_operator>
<some_value>] is valid syntax. For instance:
[query
list=1
sql=|
SELECT 'one'::TEXT AS pooh
UNION SELECT 'two'::TEXT AS pooh|]
[sql-param pooh][if-sql-param pooh eq two] Yep, that's two[/if-sql-param]
[/query]
Results in:
one
two Yep, that's two
I'm not sure why you might have problems as described. The quoting of
'steak' is unnecessary -- you only need to quote the literal if it
contains whitespace or it requires interpolation.
When you mix looping subtags with standard tags, you need to pay
attention to the order of things. The loop, query, search, etc. will
effectively product a long string of output amounting to a different
version of the loop body per row, with the looping subtags interpolated
properly. However, the standard tags will still be present, and then
the entire contents of that output is interpolated in a second pass. (I
imagine someone like Mr. Heins will speak up if I'm misinforming you).
Thus, your [tmp myscratch]steak[/tmp] doesn't get interpolated in the
same pass as the [if-sql-param]...[/if-sql-param]. But that doesn't
explain the behavior you've described.
My primary point being, there's nothing wrong conceptually with your use
of [if-sql-param], unless the quoting is causing a problem (which it
shouldn't).
It is always desirable to avoid doing standard [if ...] calls within a
looping subtag if possible. For instance, if you use:
[if type=explicit compare="[sql-param food] =~ /steak/"]
You'll run into problems if [sql-param food] happens to contain
whitespace or a double-quote. Since [if ...] is a regular (non-looping
subtag) tag, it doesn't get interpolated immediately, but the [sql-param
food] *does*. Consequently, this kind of approach is only safe when
you're absolutely certain of the sorts of data you can expect in
[sql-param food]. To be precise, what if the [sql-param food] returns
'Filet Mignon'?:
The [if type=explicit compare="[sql-param food] =~ /steak/"] comes out
of the loop as:
[if type=explicit compare="Filet Mignon =~ /steak/"]
And you have two barewords there instead of one. I don't imagine this
would behave in a desirable fashion.
Of course, I'm not giving you a very helpful response, apart from saying
"yeah, that sure looks like it ought to work."
--
Ethan Rowe
End Point Corporation
ethan at endpoint.com
More information about the interchange-users
mailing list