Query functionality

[GoogleCodeExporter]

A panel item that allows the the User to make advanced custom queries against a 
layer.
        - One layer can be queried at a time.
        - Multiple attributes within that layer can be queried against.
        - Queries should be case insensitive unless otherwise stated (option).
        - Wildcards option.

    See this for example of desired capabilities: http://suite.opengeo.org/geoexplorer/composer/ ("query" button)

Question:
How to specify which layer to use? A drop-down list of currently active layers? 
Or all selectable layers? I guess the currently-active layers as they're what 
this will modify.

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 19 Feb 2013 at 2:22

[GoogleCodeExporter]

Starting: the very good news is that integrating GXP Widgets into Heron is 
possible! So 
in the future we may say much more advanced GXP functionality coming in.

As a Proof of Concept integrated the existing GXP QueryPanel unaltered/as-is 
into Heron by class extension 
in order to have configurability and integration into the existing Heron 
SearchCenterPanel.

First test, using Dutch WFS, since it is hard to find good international WFSs. 
No protection for a too large area, so responses may be up to 15MB, also no 
user-progress feedback yet.

http://lib.heron-mc.org/heron/latest/examples/querybuilder

But I think this (wrapping GXP components) is a big way forward, also as many 
have been comparing Heron to GXP, but I see Heron more and more as the 
integrator of GeoExt and OpenLayers-based (like OLEditor) components. Already 
found improvements for the GXP QueryPanel so benefits are either way.

Original comment by jus...@gmail.com on 13 Apr 2013 at 3:07

• Changed state: Started
• Added labels: Milestone-Release0.73

[GoogleCodeExporter]

This looks really good.

----
Using "World Cities (OpenGeo)", one query - unless otherwise stated.

    population > 1234567
gives 88 features as results.

If I go back and change the query to:
    population > 12345678 (note the appended 8)
it /still/ gives me 88 results. Should only be 8 results.

---
Search seems to be case sensitive and doesn't allow for automatic wildcarding 
as an option for text.

---

The box for the operator isn't wide enough to show "between"

---
A search of:
    population between 1234567 and 7654321
Results in too many results including some that are > 7.6million. it seems to 
be showing cities ranked 1-8, then the correct results of 25-100

---

Now using multiple queries, matching "any".

longitude > 100, on its own gives 32 results. If I then add "population > 100", 
I get 97 results. But it should be 100 because *everywhere* has a population of 
> 100.

---

(no way this one will affect me, but) - if I am viewing the international 
timezone (where the map wraps around), the query by location shows:
159.3, 39.3, 194.4, 75.3
And fails to pick up anything even though I can see it onscreen. Doesn't seem 
to hand the wrap-around well.

----
The ability to cancel an "in progress" search would be good. Even if it can't 
be cancelled on the server-side, it would be good to just cancel it in Heron 
and have the application return control to the user. This also holds for the 
other types of searches/querying.

--- 
I'm possibly about to show my ignorance of basic maths here (its not my 
strongest area).
If I search for "latitude > -100", I get results from -100.284 to -122. Except 
aren't those numbers /lower/ than -100?

---
If I do a search, the map seems to resize to centre on the search results. 
Seems a little odd, especially when the search was querying by current extent 
(which is now lost due to the zoom-out and re-centre).

---
As with my other bug report, "downloading" the results includes three undesired 
columns: feature;state;fid;

---
Can we make it so the implementer can specify which options are 
enabled/disabled by default? Personally I don't want "query by location" 
enabled by default, but others might.

Original comment by jonathan...@warwickshire.gov.uk on 17 Apr 2013 at 3:58

[GoogleCodeExporter]

> ----
> Using "World Cities (OpenGeo)", one query - unless otherwise stated.
> 
>       population > 1234567
> gives 88 features as results.
> 
> If I go back and change the query to:
>    population > 12345678 (note the appended 8)
> it /still/ gives me 88 results. Should only be 8 results.
> 
This has to do with the definition of the OpenGeo World Cities WFS Layer: it 
defines "population" as a string-type. See also the DescribeFeatureType result:
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="the_geom" nillable="true" type="gml:PointPropertyType"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="City" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="latitude" nillable="true" type="xsd:double"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="Country" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="rank" nillable="true" type="xsd:long"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="population" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="longitude" nillable="true" type="xsd:double"/>
        </xsd:sequence>

This influences many of your results where "population" is included as the WFS 
will do string comparison. I tried with World Cities from FAO, the rank (int) 
field, that seems to give expected results.
As said earlier: it is hard to find good WFSes.


> ---
> Search seems to be case sensitive and doesn't allow for automatic wildcarding 
as an option for text.
Wildcarding could be made an option but case-insensitivity needs to be looked 
into, as one need to maybe use "ilike" which is not supported by all DBs.
> 
> ---
> 
> The box for the operator isn't wide enough to show "between"
> 
Ok, needs styling.
> ---
> A search of:
>   population between 1234567 and 7654321
> Results in too many results including some that are > 7.6million. it seems to 
be showing cities ranked 1-8, then the correct results of 25-100
> 
See above: string comparison.
> ---
> 
> Now using multiple queries, matching "any".
> 
> longitude > 100, on its own gives 32 results. If I then add "population > 
100", I get 97 results. But it should be 100 because *everywhere* has a 
population of > 100.
> 
See above: string comparison.
> ---
> 
> (no way this one will affect me, but) - if I am viewing the international 
timezone (where the map wraps around), the query by location shows:
> 159.3, 39.3, 194.4, 75.3
> And fails to pick up anything even though I can see it onscreen. Doesn't seem 
to hand the wrap-around well.
>
Need to look into. 
> ----
> The ability to cancel an "in progress" search would be good. Even if it can't 
be cancelled on the server-side, it would be good to just cancel it in Heron 
and have the application return control to the user. This also holds for the 
other types of searches/querying.
> 
Ok, this would be a good option. Already I extended the basis GXP query Panel, 
by giving at least some feedback and disabling the search button while 
searching.
> --- 
> I'm possibly about to show my ignorance of basic maths here (its not my 
strongest area).
> If I search for "latitude > -100", I get results from -100.284 to -122. 
Except aren't those numbers /lower/ than -100?
> 
Strange, need to look into.
> ---
> If I do a search, the map seems to resize to centre on the search results. 
Seems a little odd, especially when the search was querying by current extent 
(which is now lost due to the zoom-out and re-centre).
>
This behaviour can be configured in the ResultPanel: see also the example 
Config.js :

                           resultPanel: {
                                xtype: 'hr_featuregridpanel',
                                id: 'hr-featuregridpanel',
                                header: false,
                                border: false,
                                autoConfig: true,
                                hropts: {
                                    zoomOnRowDoubleClick: true,
                                    zoomOnFeatureSelect: false,
                                    zoomLevelPointSelect: 8,
                                    zoomToDataExtent: true
                                }
                            }
The value 'zoomToDataExtent' determines if the ResultPanel should zoom to the 
extent of the feature collection. When the result is a single point 
'zoomLevelPointSelect' is then used. zoomToDataExtent: false will disable any 
zooming.

> ---
> As with my other bug report, "downloading" the results includes three 
undesired columns: feature;state;fid;
> 
Ok, need to look into. The current ResultPanel has a mode 'autoConfig', this 
means that the grid column layout is intelligently determined from the feature 
collection. An alternative is to provide a column config, but this probably not 
feasible here. An alternative would be to have an "ignoreColumns" field. 

> ---
> Can we make it so the implementer can specify which options are 
enabled/disabled by default? Personally I don't want "query by location" 
enabled by default, but others might.
> 
This is already possible (just figured out) in the GXP QueryPanel (from which 
we derive):
                           searchPanel: {
                                xtype: 'hr_gxpquerypanel',
                                header: false,
                                border: false,
                                spatialQuery: false,
                                attributeQuery: true
                            },

The properties  spatialQuery and attributeQuery can be configured (default 
true).
See also http://gxp.opengeo.org/master/doc/lib/widgets/QueryPanel.html

So not all issues directly solved but some of the main ones hopefully.

Original comment by jus...@gmail.com on 17 Apr 2013 at 7:26

[GoogleCodeExporter]

Hmm, ok. Strings. /me wonders if our database is as well set up as it needs to 
be.
Several further thoughts as a result of this (some are probably well-outside 
spec but may be easy and/or desirable anyway and could be up-streamed):

 - What will happen when it comes to comparing "date" datatypes? Probably beyond the scope of the paid-for work, but what about a JS calendar interface? Especially useful for "between". Date searching is /always/ a pain unless there's something like this.

 - If Heron knows the datatype of the element, could it only show the operators that are compatible with that element? The numeric ones certainly won't be for "string", and as evidenced here, can easily confuse users (even ones who should know better :-) ). This particular one would make it massively more end-user-friendly.

- A "not like" would be good.

- A "Regular Expression" operator.


> Wildcarding could be made an option but case-insensitivity needs to be looked 
into, as one need to maybe use "ilike" which is not supported by all DBs.
Ah, ok. It's just that case-insensitivity is an important one for us, hence 
remembering to stick it into the spec as compared to the things I forgot. :-)


> Ok, need to look into. The current ResultPanel has a mode 'autoConfig', this 
means that the grid column layout is intelligently determined from the feature 
collection.
> An alternative is to provide a column config, but this probably not feasible 
here.
> An alternative would be to have an "ignoreColumns" field. 

Well, it seems that the three columns are consistent and all are "behind the 
scenes" columns (created by Heron/GeoExt/ExtJS/OpenLayers; none is in the 
source data. Given this, hopefully it should be easy to hardcode them not being 
exported.

Thanks for these.

Original comment by jonathan...@warwickshire.gov.uk on 18 Apr 2013 at 9:18

[GoogleCodeExporter]

Couple of other bugs/issues. They also hold for the Spatial Search and "use 
from last result".

---
The width of the drop-down itself isn't the same as the top of the drop-down

---
The drop-down contains /all/ layers declared in Heron.options.map.layers. Even 
if they're not actually active in the project (using layertrees that contain 
different things for different projects).
Ideally it would only show layers that the user currently has visible on the 
map itself. Otherwise we're going to end up with 30-50 layers.

---
Can the drop-down layers be sorted alphabetically?

Original comment by jonathan...@warwickshire.gov.uk on 18 Apr 2013 at 4:46

[GoogleCodeExporter]

> As with my other bug report, "downloading" the results includes three 
undesired columns: feature;state;fid;

Removed internal columns fid, state, feature/object from CSV/XLS Downloads. 
This will affect all Search results as these columns are filtered by the 
FeatureGridPanel. 

Original comment by jus...@gmail.com on 19 Apr 2013 at 10:45

[GoogleCodeExporter]

> Can the drop-down layers be sorted alphabetically?
Layers in ComboBox can be sorted via config prop 'layerSortOrder' ('ASC', 
'DESC' or null), default is 'ASC' (ascending by layer title). Affects all 
Searches with Layer selection, i.e. issue 177 issue 178 issue 181.

Original comment by jus...@gmail.com on 19 Apr 2013 at 11:30

[GoogleCodeExporter]

Bug?
When I try and get the drop-down for the columns in "query by attributes", it 
fails to populate. The server is returning an exception:
    <ows:ExceptionText>Single value expected for request parameter version but instead found: [1.3.0?service=WFS, 1.1.0]</ows:ExceptionText>

----
This is probably because I'm declaring my WMS URL thus:
    geoserver_wms :  'http://'+this_host+':8082/geoserver/wms?version=1.3.0',

Maybe I'm doing this wrong, (though it works well enough for everything else) 
but I guess Heron shouldn't assume the URL is a naked one (no parameters), and 
if there are parameters, should wipe them (as they're not going to be 
applicable for the WFS).

If I remove the "?version=1.3.0" it works, but my WMS queries are now 1.1.1, 
not 1.3.0.

Original comment by jonathan...@warwickshire.gov.uk on 22 Apr 2013 at 3:49

[GoogleCodeExporter]

Ha, actually just moments ago added as side remark in issue 177:

"btw I note your use of the URL:
http://wppgeog3:8082/geoserver/wms?version=1.3.0 may have two cosmetic issues 
in it:

- the 'version' parameter should really be configured as parameter in the WMS 
Layer object (or does this give you axis ordering issues? In the latter case 
there is also an xy ordering parameter). I would in general ommit WMS 1.3.0 
unless you have strict requirements like INSPIRE.
- the geoserver/wms should be geoserver/ows when URL is also used for WFS 
searches (GS always adds service=WMS) . May not be a problem with GeoServer but 
it may with other server types."

Original comment by jus...@gmail.com on 22 Apr 2013 at 4:05

[GoogleCodeExporter]

Optimisation/Bug?

Any time the "layer" is changed in the query builder, it fires off something 
like this query:
http://wppgeog3:8082/geoserver/ows?service=WFS&version=1.1.0&request=DescribeFea
tureType&typeName=Public_Data_DB:OS_BD_ELECTORAL_WSHIRE

----
However, when I click the "drop-down" menu that lists columns for that layer, 
firebug shows that the same query is sent again to populate it:

http://wppgeog3:8082/geoserver/ows?service=WFS&version=1.1.0&request=DescribeFea
tureType&typeName=Public_Data_DB:OS_BD_ELECTORAL_WSHIRE&query=

This happens if you change layers or don't change layers; it always fires it 
off twice. The second time seems redundant given its the same query.

Original comment by jonathan...@warwickshire.gov.uk on 25 Apr 2013 at 11:07

[GoogleCodeExporter]

A rather critical bug (or maybe I've just set something up very badly).
I declare a layer thus:

    //MOSAIC note - the same dataset is referenced twice, but with a different style. See the "Styles" parrameter.
    new OpenLayers.Layer.WMS(
        "2011 Mosaic - Most Frequent Group",
        Heron.WCC.urls.geoserver_wms,
        {layers: "EXP_MOSAIC_AT_100M_GRID_2011", transparent: true, format: 'image/png'},
        {singleTile: true, visibility: false, featureInfoFormat: 'application/vnd.ogc.gml', metadata: {
            wfs: {
                protocol: 'fromWMSLayer',
                featurePrefix: 'Public_Data_DB',
                featureNS: 'http://usa.opengeo.org'
            }
        }}
    ),

When I make my query, Heron sends it to GeoServer thus:
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs" service="WFS" 
version="1.1.0" xsi:schemaLocation="http://www.opengis.net/wfs 
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd http://usa.opengeo.org 
http://wppgeog3:8082/geoserver/ows?service=WFS&version=1.1.0&request=DescribeFea
tureType&typeName=Public_Data_DB:EXP_MOSAIC_AT_100M_GRID_2011" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<wfs:Query typeName="feature:EXP_MOSAIC_AT_100M_GRID_2011" srsName="EPSG:27700" 
xmlns:feature="http://usa.opengeo.org">
<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
<ogc:PropertyIsGreaterThan>
<ogc:PropertyName>B</ogc:PropertyName>
<ogc:Literal>2</ogc:Literal>
</ogc:PropertyIsGreaterThan>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

Note the "typeName="feature:EXP_MOSAIC_AT_100M_GRID_2011" - that probably 
shouldn't say "feature" there, but I'm not an XML type.

It's critical because when GeoServer receives this (or similar) GetFeature, it 
seems to stop responding to *all* future WFS queries! (and some WMS ones too). 
(ticket opened with them for that part).

Original comment by jonathan...@warwickshire.gov.uk on 25 Apr 2013 at 11:51

[GoogleCodeExporter]

Answering two questions:
> Optimisation/Bug?
> Any time the "layer" is changed in the query builder, it fires off something 
like this query:...
yes, noticed, is GXP issue but will look into

> A rather critical bug (or maybe I've just set something up very badly).
> I declare a layer thus:
I also noticed that in GeoServer latest version 2.3.1 some WFS queries will 
halt Geoserver responding to anything. In my case these were BBOX queries. 
Maybe your issue is similar. This is a Geoserver issue. Don't know if it is 
known, but there have been more issues with NSs before (with global locking 
issues as well)...The GeoServer users' mailing list is the best place for this 
issue.

Your XML looks ok. "typeName="feature:EXP_MOSAIC_AT_100M_GRID_2011" is valid 
since the namespace is declared above as 
xmlns:feature="http://usa.opengeo.org". The NS prefix string should not matter. 
The featurePrefix 'Public_Data_DB' is just for describeFeatureType needed. 
Formally the generated WFS request could use 
xmlns:Public_Data_DB="http://usa.opengeo.org" and 
typeName="Public_Data_DB:EXP_MOSAIC_AT_100M_GRID_2011". The real NS is 
'http://usa.opengeo.org', the prefix is just a handy shortcut. 

See also new Heron example:
http://lib.heron-mc.org/heron/latest/examples/multisearchcenter
(using http://suite.opengeo.org/geoserver/web with older GeoServer version: 
2.2-SNAPSHOT)

wtih layer:
new OpenLayers.Layer.WMS(
            "USA States (OpenGeo)",
            'http://suite.opengeo.org/geoserver/ows?',
            {layers: "states", transparent: true, format: 'image/png'},
            {singleTile: true, opacity: 0.9, isBaseLayer: false, visibility: false, noLegend: false, featureInfoFormat: 'application/vnd.ogc.gml', transitionEffect: 'resize', metadata: {
                wfs: {
                    protocol: 'fromWMSLayer',
                    featurePrefix: 'usa',
                    featureNS: 'http://usa.opengeo.org'
                }
            }}
    ),

and WFS req

<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs" service="WFS" 
version="1.1.0" xsi:schemaLocation="http://www.opengis.net/wfs 
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><wfs:Query 
typeName="feature:states" srsName="EPSG:4326" 
xmlns:feature="http://usa.opengeo.org"><ogc:Filter 
xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike matchCase="false" 
wildCard="*" singleChar="." 
escapeChar="!"><ogc:PropertyName>STATE_NAME</ogc:PropertyName><ogc:Literal>*ah*<
/ogc:Literal></ogc:PropertyIsLike></ogc:Filter></wfs:Query></wfs:GetFeature>

Original comment by jus...@gmail.com on 25 Apr 2013 at 3:00

[GoogleCodeExporter]

The GeoServer ticket I created earlier is here - 
http://jira.codehaus.org/browse/GEOS-5790 - Jukka did reply pointing out they'd 
had NameSpace issues before.
I just thought maybe Heron was creating XML that was Malformed or something, 
but I guess not. :-) Thanks!

Original comment by jonathan...@warwickshire.gov.uk on 25 Apr 2013 at 3:11

[GoogleCodeExporter]

Hang on, I now see that your query is a <wfs:Query and mine a <wfs:GetFeature. 
<wfs:Query's are generated by the GXP QueryBuilder. Though that should be ok, 
in my case the same kind of issue was found (in QueryBuider thus with 
<wfs-Query>) and never in other searches (Spatial/Form Search based on plain 
GeoExt). In my case the error was so bad that I skip the queries to my latest 
Geoserver since it always grinded to a halt. So what we know:

- the combination <wfs-Query> as generated from within GXP QueryPanel plus the 
latest 2.3.1 GeoServer version === lockup. Not sure if in all cases, maybe 
NS-related (default NS?). I had also several issues with the use of GML 3.1.1 
(switched to GML2) in _older_ versions of GS. 
When I have more clarity I will contribute findings to 
http://jira.codehaus.org/browse/GEOS-5790

Original comment by jus...@gmail.com on 25 Apr 2013 at 3:42

[GoogleCodeExporter]

Also happens with GeoServer 2.3.0 (what I'm still on for the next few days) - 
that's the version I originally reported about, but you're welcome to confirm 
it also happens on 2.3.1 to the JIRA in your update.

Original comment by jonathan...@warwickshire.gov.uk on 25 Apr 2013 at 3:46

[GoogleCodeExporter]

Following is a comprehensive list of issues we'd like addressed for 0.73. We 
think these are within scope. Using 0.73rc2.

Ability for user to set Case Insensitivity. (checkbox)

Ability for user to set Wildcards (checkbox)

Ability to "cancel" a search (even if just in the interface, but ideally at the 
server too).

It should only display the operators that are valid for that datatype. (i.e. no 
">" for a string).
Based on - 
http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/#built-in-primitive-datatypes 
- complete listing for reference, though I know Heron/GXP doesn't support them 
all currently.

    String:
        PropertyIsEqualTo
        PropertyIsNotEqualTo
        PropertyIsNull
        PropertyIsLike

    float,double,decimal,long,short,int,byte,nonNegativeInteger,unsignedLong,unsignedInt,unsignedShort,unsignedByte,positiveInteger
        All of them? Even PropertyIsLike?

    boolean:
        PropertyIsEqualTo
        PropertyIsNotEqualTo
        PropertyIsNull

    date,time,month,year,century:
        No idea.

All drop-downs (layer selection and columns) on all interfaces should probably 
be either:
    Width of the drop-down interface 
    OR
    width of widest item in drop-down.
    Whichever is largest. Currently most of the longer items are lost off the edge of the drop-down.


========================

The following can either be resolved with this ticket, or moved to new 
ticket(s) or ignored entirely.
Alternately for any GXP issues I/we can open a bug report with them.

Support the following operators:
         PropertyIsNull
         PropertyIsNil
    Ideally also "Not like" and regex, but I don't think the WFS spec supports them.

- Proper handling of Date data types.

- Query by location when querying on a wrap-around map doesn't give expected 
results.

- Unexpected results with negative numbers: If I search for "latitude > -100", 
I get results from -100.284 to -122. Except aren't those numbers /lower/ than 
-100?

Original comment by jonathan...@warwickshire.gov.uk on 1 May 2013 at 2:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Note - the namespace issue (http://jira.codehaus.org/browse/GEOS-5790) has been 
mostly resolved (it does require updating your hosts file if you're on Windows).

Original comment by jonathan...@warwickshire.gov.uk on 23 May 2013 at 12:08

[GoogleCodeExporter]

Ok, some progress. See example:
http://lib.heron-mc.org/heron/latest/examples/querybuilder/

Not as fast as I hoped. In my initial planning I counted too much on the GXP 
QueryPanel component to fulfill all requirements as stated in the initial issue 
description. To reiterate:

        - One layer can be queried at a time. 
==> available
        - Multiple attributes within that layer can be queried against.
==> available
        - Queries should be case insensitive unless otherwise stated (option).
==> not available - added fix as config option 'caseInsensitiveMatch', similar 
to FormPanel
        - Wildcards option.
==> not available - fix to be added

Also the Search/Cancel buttons were not part of GXP.

So in the proper FOSS-sense I started adding missing functions to a GXP clone, 
together with an issue on the GXP tracker: 
https://github.com/opengeo/gxp/issues/189 (case insensitivity). Wildcards will 
be more challenging. The per-datatype operators, they make lots of sense, but 
are moreover a huge amount of GXP-work. 

At this stage these functions are not yet done:

- wildcard support
- checkboxes for case insensitivity and wildcards
- datatype-specific operators
- drop-down widths

I suggest to add wildcard support to 0.73 and move remaining items to a new 
issue. 

Original comment by jus...@gmail.com on 23 May 2013 at 1:27

[GoogleCodeExporter]

Thanks for the update.
This sounds ok - I guess they'll be in 0.74.

On the upside, as you're already doing, much of this may be fed-back to the GXP 
project.

Just a thought - wildcards will only work for string data operators or numbers 
that are going through "like", right? No point using them for a >, or < 
comparison for instance.

Original comment by jonathan...@warwickshire.gov.uk on 24 May 2013 at 12:41

[GoogleCodeExporter]

> On the upside, as you're already doing, much of this may be fed-back to the 
GXP project.
yes, the first "pull-request" is underway: 
https://github.com/opengeo/gxp/pull/190


> Just a thought - wildcards will only work for string data operators or 
numbers that are going through "like", right? No point using them for a >, or < 
comparison for instance.
Yes, wildcards are only for "LIKE" string compares. In three variants if they 
should be placed automatically.

Hmm, it seems wildcards are already supported! Albeit not automatically 
pre/postpended. So in the example: 
http://lib.heron-mc.org/heron/latest/examples/querybuilder/
for STATE_NAME you could do a Like comparison and fill in *al* to get multiple 
results! (I did not know this). So what about adding some text that wildcards, 
even case-insensitive, are supported for LIKE compares.

Original comment by jus...@gmail.com on 24 May 2013 at 3:51

[GoogleCodeExporter]

Progress on wildcards: 

- opened https://github.com/opengeo/gxp/issues/191
- implemented in clone
- available in example 
http://lib.heron-mc.org/heron/latest/examples/querybuilder or
http://lib.heron-mc.org/heron/latest/examples/querybuildernl

For example in USA example fill in STATE_NAME like al, and see both Alabama and 
California in result.
 Configuration is similar to FormSearchPanel, via autoWildCardAttach config property.

Original comment by jus...@gmail.com on 27 May 2013 at 10:41

[GoogleCodeExporter]

I don't have a preference whether wildcards are automatically appended or 
there's some text telling the user to add them manually if desired.

Thinking about it, given this is advanced functionality, just telling the user 
they're there is probably the best option so they can manually do it if they 
want.
Easiest option for you too. :-)

Original comment by jonathan...@warwickshire.gov.uk on 28 May 2013 at 8:52

[GoogleCodeExporter]

Original comment by jus...@gmail.com on 29 May 2013 at 1:30

• Changed state: Fixed