[mapserver-users] quotes in EXPRESSION, ATTRIBUTE type

[Steve Lime]

Answers inline...

>>> On 10/25/2009 at 1:49 PM, in message
<1256496568727-3888456.post at n2.nabble.com>, Ted Spradley
<tspradley at snoogems.com> wrote:

> Hi all, hope your weekend is good!
> 
> Getting all of the Test Suite examples to function with my ver 5.4.1 of
> MapServer.
> 
> 1. Expressions can no longer be passed in the url correct? If attempted,
> they are just ignored
>     with 5.0+?

This, unfortunately varies a bit by version, but was standardized in 5.4+. You
can pass an expression but it *must* be validated. See:

  http://mapserver.org/development/rfc/ms-rfc-44.html 

You can set validation blocks at the CLASS, LAYER or WEB levels and the most
specific context trumps the others. The code checks, class, then layer and 
finally the web. So if you want to allow setting expressions on all layers without
any checking you'd add this to the WEB object:

VALIDATION
  EXPRESSION '.'
END

We're still working on assembling the definitive list of which params can be changed
via URL and of those, which need validation. In general anything that is free form
(e.g. not a number or a color) will require it.

> 2. When using expressions in classes, we treat the expressions as 'regular'
> SQL statements?
>     i.e. If the ATTRIBUTE type is a string, we quote it, and if the type is numeric we don't?

Correct, for the most part. If you're storing ints in a string column you could still
not quote things and it should work. If you have blank data though you could run into
problems.

>     The map excerpt below is from my modification of
> /tests46/expressions/test.map.  The
>     image renders as expected when I finally snapped to removing quote marks
> from
>     EXPRESSION ("[AREA]" > '%area%' ) (which did evaluate without error, but
> was evidently1 making string comparison of the values)

Correct. String testing like this is valid but isn't of that much practical use although
dates (e.g. 1990-10-20) can be tested like this.

> .
>   LAYER
>     NAME counties_hilite
>     DATA county
>     STATUS ON
>     TYPE POLYGON
>     CLASS
>         EXPRESSION ('%cty_fips%' = "[CTY_FIPS]")
>         COLOR 255 255 0
>     END
>     CLASS
>       EXPRESSION ([AREA] > %area% )
>       COLOR 212 212 212      
>     END
>   END
> .
>
> 3. When or when not to declare a CLASSITEM?  Only when inserting more than
> one CLASS for 
>     for the same attribute?  And its purpose is to basically make a
> shorthand for the SQL statement
>     in our EXPRESSION? e.g., 
>         CLASSITEM 'NAME'
>         CLASS
>           EXPRESSION ('some name') # in lieu of EXPRESSION ("[NAME]" = 'some name')
>           COLOR 255 255 255
>         END
>         CLASS
>           EXPRESSION ('some other name')
>           COLOR 0 0 0
>         END

A class item is necessary when using expressions that don't reference columns somehow. Basically
this means you need a class item with straight string or regex expressions but not for logical one.
It doesn't hurt to set the value. So, in summary:

  EXPRESSION 'foo' or 
  EXPRESSION /bar/

need CLASSITEM. While:

  EXPRESSION ('[item1]' eq 'foo' || '[item2]' =~ /bar/)

does not... Logical expressions are slower to evaluate so avoid 'em if you can.
 
> Thanks in advance!  Enjoying this more every day!
> Ted S. 

Steve