Latest Contributions by DavidWendelken

Well, instead of Basic mode I've tried Digest, NTLM and Negotiate.   Same empty sitemap.  On to other attempts. ... View more

I've rewritten my code to make multiple, recursive calls to the server via the ?f=json and it's slow as all get out.   Yuck! So, I'm going to create a service acct with GIS admin privs and create a web service to wrap the call to the ?f=sitemap option.   That way, the web service will ask as an admin and pass the data I need back much faster. For gis websites that aren't "ours" (so we don't have admin access), we'll use the new code I've written. ... View more

Item #3 above was a browser caching issue.  So at least I'm getting consistent results. Any ideas how to get ?f=sitemap to work for someone who isn't a site admin? ... View more

Did you ever find a solution?   I ask because I have a similar problem.  Documentation is sparse and, so far, not useful.   ... View more

Not for me.  Always started from a new app. ... View more

Sorry, I missed that.  (And you were very clear about it , too!) I've seen some code in the widgets about "editing related tables" but each of our gis tables are stand-alone so I've never figured out exactly what that code does.   You could certainly create a custom service in C# (or whatever) that would interact with whatever database you're using.  Javascript, Dojo and Dijit would certainly work to build a data entry screen with and could be used to call your services. Sorry not to be as much help as I thought I was being! ... View more

I've done a good deal more work on the Edit widget since my last reply. I created a java script class to act as a CustomRecordHandler.  My intent was to keep as many changes out of the widget.js file as I possibly could so it would be easier to upgrade to newer versions of the Edit widget. So, I instantiated CustomRecordHandler in the widget.js variable list.  (Naturally, that meant it had to be mentioned in the define/function list for the widget.js module.) I created a call to the _customRecordHandler object in the widget.js startup, onBeforeApplyEdits, _worksAfterCreate and _onEditorPopupShow methods.   That way, I only had a few lines of code to replicate in order to move to a new version of the Edit widget.   A lot of the info you may need is only available in the widget.js context so be sure to pass in what you need to your various methods. The onBeforeApplyEdits was the only really tricky event to handle because it is NOT called asynchronously and some of the ESRI code I wanted to execute at that point in time REQUIRED an asynchronous call.   In order to get around that problem I created a custom c# web service that could be called synchronously and didn't return results until it was done.  I don't like that particular kluge, but the only fix would be to alter the call to onBeforeApplyEdits to be an asynchronous one -- and doing that with minimized code was more than I was willing to attempt! Tasks I charged the events to achieve were: onStartup - compare the list of layers in the variable holding the Edit widget config file with the list of layers actually on the map.  If the layers actually on the map include an editable layer (which you can determine by checking the layer's capability property) that isn't in the config file-based object, I call I routine to add that layer to the config file-based object.  (The format of the data to put into the config file object is pretty intuitive.)   I also tell the map to call the same method if someone later adds a new layer to the map using the layer-add-result .  (I have to bind the method with the widget's this context before I hook it up to the layer-add-result call, or it won't have access to the info that method will need.)   That way, it doesn't matter whether the user adds an editable layer before or after the Edit widget is invoked.  PS - the map has a graphics layer that's there for some purpose and you'll want to ignore it.  I found that checking for an undefined layer capability property worked for that purpose. _worksAfterCreate - add the custom fields to the editor object.  I was adding buttons to do simplify common tasks for our users.  I created these items but hid them because they shouldn't be used for all layers, just some of them. _onEditorPopupShow - I changed the display settings for the items I created in _worksAfterCreate if they should be used for the layer being altered.   I can't definitively state that splitting up the work between the _worksAfterCreate and the _onEditorPopupShow events was necessary, but it seemed the right thing to do at the time.  onBeforeApplyEdits - pass the widget context, plus the results of a call to this.getOriginalAttributesBeingEdited(), plus the edits parameter the method receives to my custom routine.  This is the workhorse for the code that I added.  I was able to set default values that had to be determined at run time instead of design time.  As I mentioned before, you'll have to avoid or hide asynchronous calls at this point in time, the ESRI code will just ignore and proceed without waiting. I made one other mod to the Edit widget, but in the FilterEditor.js file.  I added a field where a user could type in a latitude, longitude (or other coordinate method) into it and a plot button in the _createFilterTool method. The Edit widget, out of the box, will let the user select a template from the list of editable layers and click on the map to create the object.   In our case, sometimes the users are entering data where they already know the coordinates the point is supposed to be created at, so making them navigate to that location on the map is time-consuming and unnecessary.   If the user has selected a template and entered a coordinate, pressing the plot button will call the same CustomRecordHandler object.  It calls a method that receives the FilterEditor.js this object, the coordinate value that the user entered, the this._editWidget.editor.templatePicker.getSelected() results, and an indicator that an insert is happening.  The customRecordHandler object zooms to the location on the map and then calls the chosen template's featureLayer.applyEdits method, supplying a new graphic at that coordinate in an array in the adds parameter slot, plus some callback functions to resolve or reject the promise results. Hope this helps some folks customize the editor object to their heart's content!  ... View more

To directly answer the question you asked: "No, unless you already know javascript, dojo, dijit, and the ESRI javascript api very well.  If you already know those items well, then yes, if you also have an editable service set up in esri web server and portal." HOWEVER, such a task is completely unnecessary (except for the part about "an editable service set up in esri web server and portal"). Create a web appbuilder application and add the editable service to the map.  Then add the Edit widget and configure it to allow your users to edit that service.   Piece of cake and zero programming required! ... View more

As a new dojo/dijit UI coder, it's a bit disorienting because the html files in the widget and the html output I can see in the page debugger are extremely different.   I found that adding id attributes to the elements defined in the html files really helped me figure out what run time generated html went with what. ... View more

Good point.   I'll find out. ... View more

Should not be a problem because the users won't be writing back to the file system.   The json file gets loaded into memory and the widget uses the values in memory to make its decision.  I'll be modifying the back-end to disable any attempts to write the changes back to the file system when invoked from the runtime. ... View more