What is the right way to extend/modify a popup in WebAppBuilder 2.0?

5042
4
05-18-2016 04:17 PM
TorrinHultgren
New Contributor III

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.

4 Replies
RobertScheitlin__GISP
MVP Esteemed Contributor

Torrin,

  In WAB 2.0 there is a PopupManager.js and the custom popup actions are in the PopupActions folder. Both are in the jimu folder.

0 Kudos
TorrinHultgren
New Contributor III

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. 

0 Kudos
deleted-user-0W0-oLHxDjCX
New Contributor III

Hi Robert Scheitlin, GISP​ have you have some more detailed information about this class (PopUpManager.js)? Is it possible, in example, display related data from a relationship class within the custom pop-up ?

I know the AttributeTableWidget can show this information but It doesn't looks as good as if it is self-contained within the pop-up window.

Best regards

Ezequias Rocha

0 Kudos
RobertScheitlin__GISP
MVP Esteemed Contributor

Ezequias,

  I don not work much with related data. But you should look at the RelatedRecordAction.js in the jimu.js\PopupActions folder. It looks like you should get a related records actioin button in the popup if the feature does have some related records.