find task with semi-hard coded AND

[AdrianMarsden]

Hi

I've got a web app that could potentially be used by three geographical bodies. The app features an address search, that hits a service with a single layer that has address records in.

When it is one body it is easy, the address service layer has features just for that body.

When it is one of three bodies I'd like to a) detect where they are coming from to keep a single code base - I'm sure I can do this by IP address range, login name or something

then

b) have the address layer to be used in the FIND task have all 3 areas addresses, but the find to work something like this plain English SQL;

Find where address contains <User inputted search string> AND area = <area defined by which body the user is from>

I'm not sure if this is possible - any ideas?  The find task has searchfields, and search text.  Currently my searchfields are three that contain different components of the address.  So searchFields = "Address1, Address2, Postcode" and searchText would equal "Magnolia Cottage" or something

So, if I expand the Searchfields to include "Area" (which may be "East Utopia", Gotham City", "Cursed Earth (north)" for the three bodies, I'd then have to tag one of these three onto "Magnolia Cottage" - which would fail.

I could query the incoming recordset, but this seems hard and wasteful, where a simple addition of a AND to the find task would work.

Any ideas?

ACM

[SteveCole]

Any chance you can use the UTC time offset to help you decide which to use?

[AdrianMarsden]

🙂 Nope all three areas are within 100km - but find where a user is coming from is a problem I am sure I can resolve, even if it is getting the user to choose when first logged in and storing as a cookie.

Getting the Find task to have an AND it it, is my problem

[RobertScheitlin__GISP]

Adrian,

   Why use the find task at all then. If you are able to determine the location of the user then you know which service to use and you just use a QueryTask instead.

[thejuskambi]

If you know, which area to query, can't you just filter the result of the find task?

var features = findTaskResult.features;
var outFeature = array.filter(features, function(feat){
   return feat.attributes.AREA === <area defined by which body the user is from>;
});‍‍‍‍

[AdrianMarsden]

That looks too easy   I thought about some sort of filter of the results (see OP) but hadn't followed it up as I thought it would be expensive in time.  The benefit of getting the find/query task to do it all would be that it would be querying the end SQL database, where I can ensure all the fields that form part of the query are indexed.

I'll see if I can try that

[AdrianMarsden]

Thanks for that - it took me a while to realize it was coded for AMD - I'm still on legacy code, mostly, so had to hack it into my existing code - not the first time I've done that

[thejuskambi]

If you are using legacy method, then you need to use dojo.filter instead of array.filter

[AdrianMarsden]

Many thanks - I did start to refactor it a few years back, but never finished.  On a long list of stuff to do.

[AdrianMarsden]

I may be being thick here, but my "results" object hasn't got a "features" property, it has lots of "features" (0-Number of results-1)

My function that runs when the Find is executed is

function showResults(results) {

var features = results.features;
 var outFeature = dojo.filter(features, function (feat) {
 
 return feat.attributes.LA == 'EDDC';
 });‍‍‍‍‍‍‍
.
.
.
‍‍‍‍‍‍‍‍‍‍

Which returns an empty array (it doesn't fall over, which is odd)