fix for gxp #191 - allow automatic wildcard attachment in LIKE Filters

[justb4]

See GXP issue #191. Already fixed some time ago and confirm working at several sites. Appearantly I forgot to make a Pull request. Together with issue #189 (QueryPanel: allow case-insensitive string comparison WFS Filters) which has been already merged, automatic wildcard attachment in the case of LIKE Filters is very useful, as this is user-intuitive. See an example here:

http://lib.heron-mc.org/heron/latest/examples/querybuilder and try
STATE_NAME LIKE al
(Alabama+California). Both case insensitive match and wildcarding is applied. Both are configurable (default is false).
GeoExt had in addition the option to either pre and/or postpend wildcards, but this I think is not really required for most uses.

[ahocevar]

Since this is search/query related and not filter related, this should be implemented in the QueryPanel, not in the FilterBuilder. And I think something like likeSubstring would be a better option name than 'autoWildCardAttach`.

[justb4]

Ok, for the renaming likeSubstring, or likeWildCardWrap, let me know your preference.

My reasoning was that FilterBuilder creates Filter objects such as:

     <ogc:PropertyIsLike matchCase="false" wildCard="*" singleChar="." escapeChar="!">          
              <ogc:PropertyName>STATE_NAME</ogc:PropertyName>
              <ogc:Literal>*al*</ogc:Literal>
     </ogc:PropertyIsLike>

and would, like matchCase, be reusable with other Forms, not just QueryBuilder. Also the wildcard symbols itself could in theory be modified. But yes one could argue that the string literal itself is user data provided by the FilterBuilder-caller and should not be modified internally. So another implementation could be in QueryBuilder.getFilter(), something like

if likeSubstring is true
  walk through the Filter tree
     if LIKE Filter found
        wrap string value in wildcards

Basically what FilterBuilder.attachWildCards() in my commit now is doing.

[ahocevar]

matchCase is different, because you can round-trip that without modifying the filter string. If you want to round-trip a filter that you used attachWildCards on, your filter string would change because of the added wildcard strings. This is why I don't think that FilterBuilder is the right place. And yes, QueryBuilder#getFilter would be the place to implement that.

Regarding the property name, I think that people will be looking for a way to search substrings, and a property name that tells about wildcards but not substrings may be hard to find. Hence I'd prefer something with substring in the property name.

[justb4]

Ok, new implementation committed.

[justb4]

Thanks Andreas, also for your insightful comments.