Latest Contributions by JoelBennett

I've observed the Legend widget displaying the wrong symbology for some layers; in particular, the Legend will take the symbology for "layer b" and display it for "layer a".  I'm fairly certain this is the same problem mentioned in this thread, which was observed in 4.16.  Below is a description of the cause and a proposed 4.17 solution for those who need a fix "now". The ActiveLayerInfo class has an internal dictionary for caching legend information retrieved from the server. Keys for this dictionary are generated for each service based upon whether or not the service supports dynamic layers. If dynamic layers are supported, the key is the long JSON string passed as the "dynamicLayers" parameter in the legend request. If dynamic layers are not supported, the key for the layer is the string "default". This cache is shared across all instances of ActiveLayerInfo. The intent here is good, in that it can eliminate redundant requests to the server for information that the application has already retrieved. However, the key generation is highly susceptible to collisions. For example, it is possible for multiple layers that do not support dynamic layers to share the same key "default". Since there is only one entry in the dictionary possible for this key, it will always store the most recently retrieved legend response. As a result, when layer symbology is rendered in the legend, a layer can incorrectly display the symbology for a completely different layer. A fix for this is to generate better keys that have fewer collisions. If you're using a locally hosted copy of the API, you can do this yourself.  In my solution, I've prepended the layer's URL to the key. In this case you will need to do two find-and-replace operations in the file esri/widgets/Legend.js.  Note, this solution is for version 4.17, and may not work with other versions. Part 1: search for (in function _getLegendLayers): var b=(a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default",e=I&&I[b];‍ Replace with: var b=this.layer.url+((a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default"),e=I&&I[b];‍ Part 2: search for (in function _generateLegendElementsForSublayers): p=f.hasDynamicLayers&&f.dynamicLayers||"default"‍ Replace with: p=this.layer.url+(f.hasDynamicLayers&&f.dynamicLayers||"default")‍ It should be further noted that my application uses multiple instances of the Legend widget simultaneously, but if I understand this problem correctly, it could still manifest itself when using a single Legend instance. ... View more

When creating an instance of a FeatureLayer, I've run across a bug that occurs when passing a relative URL for the service. For example: var layer = new FeatureLayer({url:"/arcgis/rest/services/someFolder/someService/MapServer/0"});‍ The layer loads its service properties ok, but when querying the service for features, it includes the layer ID in the URL twice: https://hostname/arcgis/rest/services/someFolder/someService/MapServer/0/0/query?f=json&etc=etc Needless to say, the queries fail to execute. When initializing the FeatureLayer object, the logic "thinks" it parses the URL into a path and layerID. For example, if you pass an absolute URL, the following properties will be set: //sample URL = https://hostname/arcgis/rest/services/someFolder/someService/MapServer/0 url: https://hostname/arcgis/rest/services/someFolder/someService/MapServer layerId: 0 However, if you pass the relative URL: //sample URL = /arcgis/rest/services/someFolder/someService/MapServer/0 url: /arcgis/rest/services/someFolder/someService/MapServer/0 layerId: undefined After the layer's service info gets loaded, the state becomes: url: /arcgis/rest/services/someFolder/someService/MapServer/0 layerId: 0 Queries to the service join the url and layerId properties, thus you get: /arcgis/rest/services/someFolder/someService/MapServer/0/0 The problem can be tracked down to the parse function of the esri/layers/support/arcgisLayerUrl module, which uses regular expressions to parse the service URL into various components.  This works fine for absolute URLs, but fails to work with relative URLs. One possible workaround is to convert all your URLs to absolute. However, this can be a problem if different users access the same server with different host names. Should you be using a locally hosted copy of the API, a more robust workaround would be to fix the aforementioned parse method...in this case, directly in the init.js file. The first two statements of that function are as follows: c=a.urlToObject(c); var b=c.path.match(g)||c.path.match(f);‍‍ I've inserted the following code between those lines to convert relative URLs to absolute prior to being tested against the regular expressions: if (c.path.indexOf("http") !== 0) { if (c.path.indexOf("/") === 0) { if (c.path.indexOf("//") === 0) c.path = window.location.protocol + c.path; else c.path = window.location.protocol + "//" + window.location.hostname + c.path; } else if (c.path.indexOf(".") === 0) c.path = window.location.protocol + "//" + window.location.hostname + window.location.pathname.substring(0, window.location.pathname.lastIndexOf("/")) + c.path; }‍‍‍‍‍‍‍‍‍ However, I've minified it when updating the init.js file. So basically, in init.js, you would search for: c=a.urlToObject(c);var b=c.path.match(g)||c.path.match(f); and replace it with: c=a.urlToObject(c);if(c.path.indexOf("http")!==0){if(c.path.indexOf("/")===0){if(c.path.indexOf("//")===0)c.path=window.location.protocol+c.path;else c.path=window.location.protocol+"//"+window.location.hostname+c.path;}else if(c.path.indexOf(".")===0)c.path=window.location.protocol+"//"+window.location.hostname+window.location.pathname.substring(0,window.location.pathname.lastIndexOf("/"))+c.path;}var b=c.path.match(g)||c.path.match(f); As an aside, relative URLs worked fine in 3.x, and the 4.x documentation doesn't specify that absolute URLs are required. This solution is specific to 4.16 and may not work in other versions. This post is for the benefit of those like me who experience this problem, and need a solution *now*.  I will not respond to requests to submit this to ESRI support. ... View more