Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure that OBJECTID (or similar) field need not be included in the 'fields' constructor option #366

Closed
jgravois opened this issue Oct 10, 2014 · 5 comments

Comments

@jgravois
Copy link
Contributor

it'd be nice for users if they weren't required to specify an OBJECTID (or other field required for indexing) when they want to define "fields" in the FeatureLayer object constructor.

var myFeatureLayer = new L.esri.Layers.FeatureLayer(url, {fields: ["OBJECTID", "COOLFIELD"]}).addTo(map);

please assign this issue to me. i can look into how exactly we might refactor to make this change. at a minimum the existing requirement needs to be documented more clearly.

reference: SE

@jgravois jgravois changed the title ensure that OBJECTID or similar field ensure that OBJECTID (or similar) field need not be included in the 'fields' constructor option Oct 10, 2014
@jgravois
Copy link
Contributor Author

first draft of fix can be found here

@patrickarlt
Copy link
Contributor

Unfortunately this might not be the most efficient way to accomplish this. Here is how the code will flow now.

  1. Instantiate L.esri.FeatureLayer with ['Name', 'Date']
  2. Kickoff metadata request since we dont have an ID field
  3. Add layer to map
  4. start requests for all features in the current view with ['Name', 'Date']
  5. at this point we have at least 5 requests (1 for metadata, 4 for features) when the metadata comes back it will force a refresh which will kickoff more requests. The only way to really solve this is to wait for the metadata request to finish before requesting features which means waiting for a round trip.

This approach would probably still produce an errors and issues since the features in the initial requests (before we know the ID field) will still be processed.

Another approach would be to simply check all the fields and see if they contain one of FID, OBJECTID or ObjectId ect...

Since 99% of services will have one of these common identifiers we could console.warn and push a message to developers instead which isn't ideal but is the only way to accomplish this without waiting for the metadata.

@jgravois
Copy link
Contributor Author

that makes sense. how about something like this then?

@patrickarlt
Copy link
Contributor

Yeah this makes more sense. you will also need to check for console and console.warn since they will be undefined in IE until you open the dev tools.

So the final check should look like if (oidCheck === false && console && console.warn){.

Would also be good to tweak the warning message to say something about including the field that contains the unique is of the features in the fields option.

@jgravois
Copy link
Contributor Author

resolved by #371

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants