Enabling a Custom Geoprocessing Widget in WAB Fails

[MichaelCollins6]

Hi all:

I am getting the following error when attempting to publish a widget to WAB in our Enterprise Portal. The file is definitely there so I am hoping this is a simple issue, but am utterly stuck. This was replicated using the stock geoprocessing widget as well by publishing that to the same server.

GET https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings net::ERR_ABORTED 404 (Not Found)

init.js:37 Error: scriptError at c (init.js:11) at HTMLScriptElement.<anonymous> (init.js:35)

init.js:37 src: dojoLoader

init.js:37 info:

1. (2) ["https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings", Event]
   1. 0: "https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings"
   2. 1: Event {isTrusted: true, type: "error", target: script, currentTarget: null, eventPhase: 0, …}
   3. length: 2
   4. __proto__: Array(0)

[WenhaoWu]

I reread your post and realized that the "RecordSetEditorChooser.js" was referring to the Geoprocessing widget, so that's why I couldn't find it in the AddData widget....

and the data-dojo-type="widgets/AddData/search/ScopeOptions" is something hopefully we don't need to modify, right?

Thank you!

[WenhaoWu]

Also sir @DavidWilton , when you get a chance, could I possibly get your input on my process of developing and deploying a custom widget? That'd be super helpful, and many many thanks!

My process is this:

- downloaded from the ArcGIS Web App Builder SDK: https://developers.arcgis.com/web-appbuilder/guide/getstarted.htm

- went into the /server side folder and found the AddData widget folder where I need to make some changes to add a simple business logic for my use case

- tested the widget locally within the downloaded SDK/Dev Edition and it worked well

- packaged this modified AddData widget and uploaded and hosted on a Google GCP server with a Manifest JSON

- Add this widget as an App Extension using this Manifest JSON pointing to my custom AddData widget

- imported this custom widget to an existing Web map app I have on my ArcGIS Portal

- encountered the same error "ScriptError: ..../dojo/i18n!../nls/strings" (but hopefully adding local relative nls folders can work?)

Some additional tests I have done:

- I also checked my local server side widget folder, I found there are 15 Javascript files that contains this path "dojo/i18n!../nls/strings" in their define[] statement, as you had described above. I tried to replace this line with a direct URL link pointing to the strings.js file hosted on my GCP, but neither worked for my local environment or on the Portal. Another WAB out-of-box widget that contains this"dojo/i18n!../nls/strings" is the Edit widget. I even packaged this default Edit widget and tried importing it as a custom widget to my portal apps, but it gave me the same Script Error.....

Thank you!

Wen

[VLRoyrenn]

No, it looks like an issue with the string being incorrectly built when the Dojo i18n loader is used, it's not a path resolution difference between the Enterprise portal and the developer's edition.

The ressource "dojo/i18n!../nls/strings" is supposed to resolve into something like "arcgis.example.com/widgets/AddDataStock/nls/strings.js" and the localized file "arcgis.example.com/widgets/AddDataStock/nls/fr/strings.js", with the resulting module being cached as "arcgis.example.com/widgets/AddDataStock/nls/strings.js/fr-fr". When added to n enterprise portal, however, it instead resolves into "arcgis.example.com/widgets/AddDataStock/nls/strings" when loaded by the dojo/i18n loader from a dojo module, like what the AddData and Edit widgets do. This misses the ".../strings.js/fr-fr" module already in cache and tries loading a file that does not exist. When using WAB dev edition, you'll notice no nls file gets loaded when opening either widgets, since they are loaded as the app launches.

The suggested workaround of just requiring "../nls/strings" with no i18n has the issue of completely disabling translations for all parts of the widget that loaded the strings this way, defaulting to english.

I can't say where the extra .js is normally supposed to come from (it's not the legacy loader checks, they don't run in the Dev edition anymore than in my enterprise portal). This is proving very unpleasent to debug, ans I certainly won't miss Dojo once we move to Experience Builder.

[VLRoyrenn]

So it really looks like an interaction between the "dojo/i18n!" loader, Dojo's relative path resolution, the stock/custom widget path split in the Enterprise Portal, and possibly the _WidgetsInTemplateMixin.

Debugging imports inside minified AMD code bundles has proven frustrating enough that I'm not going to try figuring out the precise cause of the issue. I've instead completely removed all relative imports from the problematic widgets and replaced them with the likes of "dojo/i18n!widgets-custom/AddDataCustom/nls/strings" and data-dojo-type="widgets-custom/AddDataCustom/search/ResultsPane", which seems to have solved it.

I have to declare my own widgets-custom package in ArcGIS/Portal/apps/webappviewer/init.js in order to have a root location for the custom widget location in the Enterprise Portal, in my case arcgis.example.com/widgets/, so that it can be correctly resolved.

dojoConfig.packages = [{
    name: "widgets",
    location: window.path + "widgets"
}, {
    name: "widgets-custom",
    location: "//" + window.location.host + "/" + "widgets"
}, {
    // Keep everything else the same
}];

Note that dojoConfig.packages is declared in two separate locations in that file, you might need to change both.

WAB Dev edition can make a similar modification in `client/stemapp/init.js` and `server/apps/<n>/init.js` by just pointing to the same location as the widgets package, so the references are also valid there.

@WenhaoWu: That might solve your problem, in case you haven't found a workaround yet.