Retrieve all field values using FindTask

[BabbageOcelot]

Hello all,

I'm looking to implement some rudimentary filtering on our map system, to be configured by the user. The use case would be to find all incidents of x, with the attribute y (which can be selected from a dropdown list), from layer z.

Getting layer and attribute info is easy. I can retrieve all field names (via a long-winded and expensive method using featureLayer.Fields), but using a FindTask, I can't search on "everything", so to speak. This means I can't populate the dropdown with all possible values.

Ideally, I'd like to use a FindTask with FindParameters.searchText as "", or "*", but neither of those seem to work.

I realise this is going to be an expensive operation at the server end, so I'll be limiting the opportunities for users to make this sort of call - but at the moment I can't seem to find a way of doing it anyway. Really, I want to avoid having to create SOAP proxy pages, using ajax, and all manner of other convoluted methods!

Cheers, Ben.

[derekswingley1]

Hi Ben,

I would encourage you to re-think this and consider accepting user input instead of putting everything on the client from the start. Putting everything on the client will slow down initial app load time and probably provide a less than ideal user experience. Why not let your users specify some text, then use that as the searchText on your findParameters?

If you really want everything on the client, you probably want to use a query task, not a find task. Pre the documentation, the find task requires some text(not wildcards):

Search a map service exposed by the ArcGIS Server REST API based on a string value.

A query task will let you specify a where clause of something like "1=1" to get all values (or the max number of records returned by your service, 1000 if you're using version 10 of ArcGIS Server). If you do this, you'll want to specify returnGeometry=false so that you're not needlessly pushing geometry across the wire. The one drawback here is that a query task will only work against a single layer.

Finally, I understand wanting to avoid SOAP, that's understandable. But why the aversion to AJAX?

[BabbageOcelot]

Hi Ben,

I would encourage you to re-think this and consider accepting user input instead of putting everything on the client from the start. Putting everything on the client will slow down initial app load time and probably provide a less than ideal user experience. Why not let your users specify some text, then use that as the searchText on your findParameters?

Hey Derek,

Ideally I'd like to have both as an option - either type the value if you know it, or use a 'get values' function to populate the first 25, for example. The need for this stems from replacing an existing application which offers the same functionality - our users tend to get sniffy when things like that change (I can hear a chorus of "Can't we just have the old one back?" already). It also needs to be wizard-simple.

If you really want everything on the client, you probably want to use a query task, not a find task. Pre the documentation, the find task requires some text(not wildcards):

A query task will let you specify a where clause of something like "1=1" to get all values (or the max number of records returned by your service, 1000 if you're using version 10 of ArcGIS Server). If you do this, you'll want to specify returnGeometry=false so that you're not needlessly pushing geometry across the wire. The one drawback here is that a query task will only work against a single layer.

Fair enough. We might have to look at something in the query task, but I was rather hoping for a wildcard-type search.

Finally, I understand wanting to avoid SOAP, that's understandable. But why the aversion to AJAX?

Simple answer - development time! I was rather hoping there was a mechanism within the API I could use to do this quickly. Given it's not, we'll probably just have to do the processing at the server end and ajax it up.

Many thanks,

Ben.