LocalLayerWidget Version 2.5 and AccessifizrWidget Layer - 09/28/2017

154510
507
01-08-2015 07:55 AM
AdamDrackley
Frequent Contributor

I've been having a blast playing around with the new Web AppBuilder, and have taken a few cracks at putting together some custom Widgets that I'd like to share with the community.  I hope these can assist in everyone's future Mappmaking endeavours!

LocalLayerWidget

LocalLayerWidget v 2.5

September 28 2017 : LocalLayerWidget v2.5 released:  This major release includes the following enhancements for the widget.  Thanks to everyone who's donated!:

Release LocalLayerWidget 2.5 · cmndrbensisko/LocalLayer · GitHub 

  • Support for 2.5 Release of ArcGIS Web App Builder
  • Support for Custom Layers via Transformers
  • Demos and sample apps
  • Prototype 3D Widget
  • Dynamic GUI changes at runtime and css insertion via odds.json/odds.css
  • And more!

November 14, 2016: LocalLayerWidget v2.2 released:  This major release includes the following enhancements for the widget:

Release LocalLayer v2.2 · cmndrbensisko/LocalLayer · GitHub 

  • Related Table Viewing and Editing
  • ImageService Viewing and Popups
  • WMS Service Viewing and Popups
  • Ability to integrate with the IncidentAnalysis widget
  • Hide Layer In Legend capability added
  • Dynamic mode added, allowing for URL-fed configuration files
  • And more!

May 18, 2016: LocalLayerWidget v.2.0 released:  This substantial change for Web App Builder v.2.0. removes the need to edit any core files in the Web App Builder, unlike previous versions.  A slight change will still be necessary for the AttributeTable widget to work properly with LocalLayerWidget layers.

  • https://github.com/cmndrbensisko/LocalLayer/releases/tag/v2.0
  • Enhancements:
    • Added autorefresh capability for dynamic layers, and sub-minute decimal values can be specified for time.
    • Added support for non-consecutive sublayer numbering to support 10.3.1 mapservices
    • Editor Tracking via an organizational Active Directory instead of ArcGIS Online User now supported
  • Bug Fixes:
    • View Attachments now works for Dynamic Layers
    • Addition of GeoJson layers fixed
    • Fix to MapService sublayer visibility when no sublayers are selected to display by default.

Mar 29, 2016: LocalLayerWidget v.1.3.1 released; Contains bugfixes to v.1.3. related to custom rendering for Feature Layers and toggling sublayer visibility in the LayerList widget.

Mar 22, 2016: LocalLayerWidget v.1.3 is now available!  (Note the version naming change; Version 1.3 refers to its compatibility with v1.3 of the WAB - This is indeed the latest version of the widget as of March 22, 2016).  Be sure to read the github page to see what tweaks need to be made to ensure that everything continues running smoothly in version 1.3 of the Web AppBuilder.

  • Includes support for GeoJSON and WebTileLayers
  • Custom Symbology and Labelling Options for Feature Layers
    • Currently requires the use of playground to generate custom json layer and label styling for Feature Layers.  For more information, please follow the instructions on the Github page.

Feb 10, 2015: LocalLayerWidget v.1.5 is now available!  This release contains full support for adding Tiled layers to your application directly from ArcGIS Server, in addition to the Basemap, Dynamic, and Feature layers available before.  Feel free to grab the widget from our Release page located at https://github.com/cmndrbensisko/LocalLayer/releases.

Feb 2, 2015: LocalLayerWidget v.1.2 is now available!  This release provides a great GUI developed by Robert Scheitlin to more easily add Feature, Dynamic, and Basemap layers to your ArcGIS Web AppBuilder Applications.  Take it for a spin, and please keep us informed of any bugs or desired enhancements through our Github Issue Tracker located at https://github.com/cmndrbensisko/LocalLayerWidget/issues.

Jan 12, 2015: Note that LocalLayerWidget v.1.1 is now available, which provides Click-To-Identify support and the option to add Feature and Basemap layers in addition to Dynamic layers.

The LocalLayer Widget is intended to allow the direct addition of MapServices to an ArcGIS Web AppBuilder application, without needing to wrap the desired services in an ArcGIS Online/Portal Web Map.

https://github.com/cmndrbensisko/LocalLayerWidget

Basically, your basemap will still need to come from Portal/AGOL, but otherwise you just provide direct URLs to your own MapServices in the widget's configuration settings.  The MapServices should load and display as usual in the map, and cooperate with the Legend, LayerList, and Attribute Table widgets. Click-To-Identify functionality won't work currently, though, because the current WAB implementation relies on Portal for all the popup info.  As stated in the January 12th 2015 release, popups are fully customizable.  Note that it's not an in-panel widget, so you'll need to follow a few extra steps in the project's Readme file.

AccessifizrWidget

Let's make Mapps accessible for everyone!  With an eye on WCAG compliance, the Accessifizr Widget is designed to help make web applications keyboard navigable without having to modify core application code and UI.

https://github.com/cmndrbensisko/AccessifizrWidget

Information about how to configure this widget is available in the core Accessifizr.js library project available here‌, but the gist is that you create a JSON-based 'roadmap' detailing the keyboard navigation of your web application, and how it should change in response to users entering modal menus, hitting the escape button, etc.  For applying descriptive alternate text to page elements, the widget leverages dojo's built-in internationalization support to specify multilingual alternate text strings.  The end result is a web app that, hopefully, is a bit easier to use for people with mobility or visual challenges.

507 Replies
AdamDrackley
Frequent Contributor

Sorry to leave you two hanging on this.  I hadn't tested the widget against secured services until now, but you guys seem to be running into another face of the same bug that necessitates the edit to your LayerInfoForMapService.js file.

On line 406 of jimu.js\LayerInfos\LayerInfoForMapService.js file, find the line that says:

      var url = this.originOperLayer.url + '/layers';

And change it to:

      var url = this.originOperLayer.layerObject.url + '/layers';

And let us know how far this gets you.  Hope this helps.

0 Kudos
BillSpiking__GISP
Frequent Contributor

You're the Man Adam!  The Attribute Table works perfectly now!  I've been banging my head on that one for hours .

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

Thanks Adam! It's not quite working for me, it's wanting me to log in each time.  I'll take a closer look in the morning, since it's still probably a proxy issue on my end.  But I can at least customize the widget now, so a major step forward.

0 Kudos
AdamDrackley
Frequent Contributor

The login prompt appearing each time is likely a security feature built into the WAB.  I don't believe the proxy is actually used at all in the authentication process, unless your proxy has been specifically programmed to take care of this, but I'll take a closer look this evening.

If it's desired functionality, we might be able to get the Widget to store an authentication token in a cookie, and not prompt the user again until the cookie expires, but we might need to make this something you clearly opt-into in the setup: Some users might not want authentication tokens stored, and might enjoy the added security that comes with needing to authenticate each time the app is viewed.

Alternately this kind of thing might be able to be handled entirely in the Proxy, though it would require storing user credentials directly in your Proxy Config, and potentially any users could spoof their way into seeing your secured services by going through an auto-authentication proxy.  It depends entirely on your specific workflow which you'd be more comfortable with.

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

So, with clear mind this morning, I remembered that I need to make the change in the \server\apps\<#>\jimu.js\layerInfos\LayerInfoFosMapServices.js too, not just the client\sitemap folder, since I already had the site created and modified.  Once I did that, the attribute tables are coming up, as expected.  yeah!

I agree, that the login screen is desired at times for security, and should not be turned off automatically or by default  (although it's a pain when developing).  My latest version of my flex builder app does the same, and I think it has more to do with how our security is set up now (with SSL/https finally in place) than the builder apps.  Since my first task is converting our in-house-only flex app to js, I can live with the login.

Thanks again for your response Adam Drackley re: the secure attribute tables!

0 Kudos
BarnabyRockwell
Deactivated User

Adam,

Your cookie idea for storing AGOL login info sounds great to me.

Cheers,

Barnaby

0 Kudos
BarnabyRockwell
Deactivated User

Adam, this edit fixes my attribute problem as well.  So the issue #1 in post 500 messages above () is now also fixed.  Good job!

Cheers,

Barnaby

0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Rebecca,

   Using the Local Layer widget will not change the projection of the map away from what the WebMap that is used as the starting point uses. What I mean by this is if you just open WAB and go straight to the widgets and configure your local layers then your initial web Map is goint to be in web mercator and even though the Local Layer widget replaces the content of the map the maps projection and LODs will remain in 102100 (Web Mercator). So if all your layers are Alaska Albers then you need to start with a web map that is in Alaska Albers. If you find that this is not the issue then please post back and I can dig deeper.

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

Robert, I did start out with a map in Alaska Albers (from my web mapID), but I may install a "Fresh" WAB instance in case it's holding on to something else.  but I'll try a few other things first.

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

Roberti, I'm thinking it has something to do with my proxy "location" and working with WAB (i.e. not deployed to my IIS).    Do you know if/where the proxy.config needs to be located in the WAB file structure??

Some of the issues I was having:

  • If I unchecked "Use Proxy" the base would show up and stay on, but of course my secure layers would not (but I did get it to prompt for log in at one point, which would be semi-ok).  It's strange that it doesn't like the proxy since for the basemap, which is actually "public", my proxy is used just as a passthru, and if I use my base from the dev server (with a similar proxy.config file) it seemed to work.
  • The reason I'm wondering if I need the proxy.config in the WAB file structure is I get an error, and it was giving me a 400 or 401 error with this type of message.

But, I've wiped that all out and starting clean again.  I have reinstalled and have added your three widgets, and the localLayer (with the required modifications to the files...but none are configured yet).  I've fired WAB up, attached to my AGOL portal, and started a new website.  It brings in a default webID, even though I have not requested one with this new setup.  When I run this, I do see an error, maybe unrelated

    InvalidAccessError: A parameter or an operation is not supported by the underlying object

...if (!def.isFulfilled() && (loadedSheet.cssRules && loadedSheet.cssRules.length |

for line 124 of utils.js    which my guess is nothing that either of you messed with (i.e. standard 1.0 release?) but maybe something is conflicting.  I may go back to just one custom widget at a time.

Anyway....

Robert wrote (parsed be me)

.... What I mean by this is if you just open WAB and go straight to the widgets and configure your local layers ..... So if all your layers are Alaska Albers then you need to start with a web map that is in Alaska Albers. If you find that this is not the issue then please post back and I can dig deeper.

I know Adam Drackley‌ at one time said we have to have a portal webID as a base map.... but is their away around that now?  I'm wondering if my public and secure tokens between the two sites are what's causing the issue?  Just pulling things out of the air right now....since once I got my proxy to work, I forgot most of what I did.

So, maybe more than can be tackled here, but in case you have any ideas.  I'm determine to get it working!

0 Kudos