POST
|
Hi Dvirus b, We had been hoping for a solution where we could deploy WebAppBuilder running under Node.js, without portal, and federate it with our ArcGISOnline subscription to allow a customizable multiuser WebAppBuilder experience. That's the vision that we're giving up on because Esri's only supporting this scenario under a Portal umbrella. And while we're disappointed, we can think of some pretty defensible reasons why they chose that route, among them the concerns you raise. To your first question - adding a settings screen for widgets is probably more helpful to those running WAB under Portal than those running standalone WAB - mostly because the latter are likely to be developers who skip past GUIs and go straight to config files. But it's still a best practice. Hope that helps.
... View more
05-07-2018
03:17 PM
|
0
|
0
|
484
|
POST
|
No, it's pretty clear that Esri doesn't intend to support WAB as a standalone multiuser solution and their answer to this question is a full-fledged Portal installation. We've tested that, and it works fine - if you throw enough hardware at it. But that's only for the configurator portion of WAB . If you use either AGOL or Dev Edition for an initial configuration and then dump it out for further customization, it runs fine on any web server, no need for Node.JS or any other server-side components. We do a lot of that because of our limited hosting options.
... View more
05-03-2018
09:05 AM
|
1
|
2
|
484
|
POST
|
We never did get the developer edition working in anything other than a sandbox environment for "communal development", but this business case is one of the drivers towards us exploring Portal for ArcGIS. Portal's a heavy lift from a resource and management perspective, but it does offer at least a few compelling options not available in AGOL.
... View more
05-23-2017
09:10 PM
|
1
|
0
|
484
|
IDEA
|
The Legend widget in the ArcGIS JavaScript API (Both 3.18 and 4.1) seems hardcoded to always place low values at the bottom and high values at the top, regardless of the order in which they are configured in a map service. Cartographic authorities suggest that there isn't a correct order - valid arguments may be made for either sort order, at the discretion of the cartographer and the intended message. And some cartographers feel very strongly about the order in which their legend appears, and are unnerved when that order is reversed when incorporated into a mapping application or viewed in ArcGIS Online. We'd like to request that either the legend follow the order set in a map service, or that ArcGIS Online users (and developers using the API) be given the ability to set the legend class order they feel is most appropriate.
... View more
11-02-2016
03:01 PM
|
4
|
2
|
295
|
IDEA
|
The Legend widget in the ArcGIS JavaScript API (Both 3.18 and 4.1) seems hardcoded to always place low values at the bottom and high values at the top, regardless of the order in which they are configured in a map service. Cartographic authorities suggest that there isn't a correct order - valid arguments may be made for either sort order, at the discretion of the cartographer and the intended message. And some cartographers feel very strongly about the order in which their legend appears, and are unnerved when that order is reversed when incorporated into a mapping application or viewed in ArcGIS Online. We'd like to request that either the legend follow the order set in a map service, or that ArcGIS Online users (and developers using the API) be given the ability to set the legend class order they feel is most appropriate.
... View more
11-02-2016
03:01 PM
|
3
|
1
|
261
|
POST
|
Hrm, we started there, but were puzzled when that code (jimu/PopupActions/PopupActions.js) never appeared to be required and/or executed. In revisiting this path, though, we did find that jimu/PopupActions/PopupAction is also defined within jimu/main.js, and we were able to re-implement our version 1.0 hack by augmenting the _onSelectionChange method there. So I guess our practical problem is solved, but we're still curious about why the more elegant and versatile dojo .extend inheritance solution doesn't work. Much appreciated, Robert.
... View more
05-19-2016
11:40 AM
|
0
|
0
|
734
|
POST
|
In version 1.x of WebAppBuilder popups seemed to be handled by the AttributeTable\Widget.js code, and by adding a little bit of code to the jimu/InfoWindowAction section of that Widget.js file we were able to execute a little bit of JavaScript code after a popup had been rendered to enhance and improve aspects of the popup. It was a bit of a hack, but it worked - happy to share more details if anyone's interested. In version 2.0 of WebAppBuilder, though, it appears as if all of the popup rendering is performed using code from the JavaScript API - js.arcgis.com, specifically esri/dijit/PopupRenderer - so our hack won't work unless we were to pull that code locally, and we'd really prefer not to do that. Instead we're trying to do things the right way - by using Dojo Inheritance to extend the PopupRenderer class. dojo/_base/declare — The Dojo Toolkit - Reference Guide We know that any extension has to occur after the API has been loaded, so we're working within the dynamic-modules/postload.js file, which does seem to be executed at the right time. Our very simple code block is here: define(['esri/dijit/PopupRenderer'],
function(popupRenderer){
return popupRenderer.extend({
_handleComponentsSuccess: function(){
this.inherited(arguments);
console.log("success");
}
});
}); According to our understanding, this inherits the existing PopupRenderer class, it then returns an extended version of that class with an altered _handleComponentsSuccess function, and this.inherited(arguments); is the technique to use to call the superclass method (so we don't overwrite it). In practice, everything about this code works except for that calling of the superclass method - a "success" is logged to the console every time a popup is supposed to be rendered, but the internal content of the popup is never populated - the original _handleComponentsSuccess code is never executed (We've tried extending the .startup function as well). So what are we missing? Is there a different way to extent esri dijits? Or are we misunderstanding the concept of Dojo inheritance? Or is WebAppBuilder just a different ballgame? If we can get this right, it seems like it should be a really elegant way to perform small enhancements. Thanks in advance.
... View more
05-18-2016
04:17 PM
|
1
|
4
|
5553
|
POST
|
Thanks, Robert, it sounds like our experience in discussing this pattern with Esri developers has been consistent with yours - that it wasn't anticipated or intended. Nevertheless, we have been hearing this functionality repeatedly and insistently requested by our customers - they want a Web AppBuilder experience similar to the ArcGIS Online version where they have the freedom not just to tweak a few widget settings on a preconfigured app, but to choose from an expanded list of widgets (and themes) in a fully online interface. And despite the fact that Esri seems to have not anticipated this scenario, the developer edition of Web AppBuilder functions surprisingly well in this shared environment, with only the few small aforementioned issues. We can and will submit this as an enhancement request on ideas.arcgis.com, but wondered whether the developer community was hearing similar requests and had already managed to hack together a solution. As always, very much appreciate your insight!
... View more
03-25-2015
10:39 AM
|
2
|
0
|
896
|
POST
|
We (David and I) successfully followed the instructions for running the WAB as a windows service, and multiple users can connect using either Esri or enterprise credentials (via SAML) and confgure applications, however two main concerns arose in our testing: We don't seem to have the ability to lock access down to our organization - that is, any user can visit the site, enter their ArcGIS Online for Organizations URL (or even a portal URL) and use our custom standalone WAB with their portal. Not exactly the service we'd intended to provide to the public. When a user connects, they are only shown applications that they have configured themselves, however on the file system applications are identified by simple integers (1,2,3,etc) and nothing prevents a user from specifying any integer and viewing and editing applications authored by other users (provided they have access to the same source web map). This is definitely a dealbreaker for use in a shared environment. And although we had some success using IISNode and the IIS7 URLRewrite module to try and route traffic from port 80 to node.js in a controlled manner (without routing 100% of traffic there), there were too many calls to the node.js root (rather than a predictable, filterable path) to make this a practical reality similar to a tomcat webapp. Discussions with Esri's developers and support techs haven't gotten very far, if anyone else out there is trying to work through some of these details, we'd appreciate the discussion. Thanks!
... View more
03-24-2015
04:24 PM
|
1
|
4
|
896
|
IDEA
|
For years web developers have been able to interact with the fantastic Dynamic Layers functionality of ArcGIS Server services to alter the symbology of services on-the-fly, but users of Esri's flagship desktop software have been denied the same ability. We've given up hope for this functionality to be included in ArcGIS Desktop, and were disappointed when the final release of ArcGIS Pro also lacked this feature. Please, it can't be that hard.
... View more
03-09-2015
02:44 PM
|
49
|
2
|
1484
|
POST
|
Both the SOAP and REST interface for ArcGIS Server services natively support a spatial filter on the query method, and have since version 9.3.1. http://services.arcgisonline.com/ArcGIS/SDK/REST/index.html?query.html But the ArcGIS Explorer SDK ServiceChildLayer.Query method only accepts a simple attribute whereclause. http://help.arcgis.com/en/arcgisexplorer/1500/sdk/componenthelp/index.html#/Query_Method/000300000tw8000000/ It seems as if all the power in ArcGIS Explorer is with FeatureLayers, and it's great that you can create in-memory FeatureLayers from services, but debilitating that in order to perform a spatial query on a service layer (something that service natively supports if query is enabled) in ArcGIS Explorer, you have to first select ALL of the service layer's features (up to the QueryFeatureLimit, of course) into a FeatureLayer and then perform the spatial query. Any workarounds or recommendations?
... View more
03-21-2011
02:16 PM
|
0
|
1
|
878
|
POST
|
Hi JavaScript API folks, According to the documentation of a GraphicsLayer,: http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/graphicslayer.htm Graphics layers can be reordered within the group of graphics layers. However, the graphics layer in Map.Graphics is always on top. Also, all graphics layers are always on top of TiledMapServiceLayers and DynamicMapServiceLayers. This isn't quite true. On the page, Graphics Layers seem to end up in the following element: <svg width="821" height="656" style="overflow: visible; position: absolute; z-index: 20;" id="mapDiv_gc">...</svg> which as best I can tell is hard coded with a z-index of 20. Fine, as long as you never have more than 21 map layers, since other map layers appear to be added with ascending z-index values. For those of us just nutty enough to add more than 21 layers, though, our graphics get buried. The z-index value isn't all that difficult to change after the fact with a dojo.style('mapDiv_gc','zIndex',40); command, but should this really be necessary - especially when the documentation is so adamant about graphics layers always being on top of other layers? Thanks so much!
... View more
09-29-2010
04:19 PM
|
0
|
1
|
797
|
POST
|
Ahhh, those links are very helpful - I was led astray by all the links on this page http://resources.esri.com/help/webapi/javascript/arcgis/index.html which include only the old documentation. Thanks for clearing that up, perhaps a redirect on that older page might be in order?
... View more
06-30-2010
11:04 AM
|
0
|
0
|
573
|
POST
|
Our sites just started throwing errors "BingMapsKey must be provided." We've got a Bing Maps Key of our own, but neither ajpfister06's code, nor simply adding our key as a "BingMapsKey" parameter to our VETiledLayer initialization seems to be working today. Was there a plan to include documentation of this new requirement at some point, or are we forced us to switch back to v1.6 to maintain a working site?
... View more
06-30-2010
10:50 AM
|
0
|
0
|
573
|
Title | Kudos | Posted |
---|---|---|
1 | 03-24-2015 04:24 PM | |
1 | 05-03-2018 09:05 AM | |
3 | 11-02-2016 03:01 PM | |
4 | 11-02-2016 03:01 PM | |
49 | 03-09-2015 02:44 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|