Answers inline... >>> On 10/25/2009 at 1:49 PM, in message <1256496568727-3888456.p...@n2.nabble.com>, Ted Spradley <tsprad...@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 _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users