Re: [ic] if-sql-param question

[Ethan Rowe <suppressed>]

JT Justman wrote:

> suppressed 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
suppressed
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users