Refactoring the SNH Data Table Widget, Part III

“More than the act of testing, the act of designing tests is one of the best bug preventers known.”
Boris Beizer

Now that we have refactored the various SNH Data Table widgets and added the missing support for clickable aggregate columns and conditional buttons and icons, it’s time to run everything through its paces and make sure that it all works. To begin, let’s just see if the stuff that was working is still working now that we have made all of these changes to the artifacts and added these new features. A good place to start would be with the User Directory, as that little project utilizes a number of different components that were affected by the changes.

Primary User Directory page

Well, that seems to work, still. Changing perspectives and selecting different states all seem to function as they should as well, as does paging through the data and sorting on the various columns. So far so good. This tests out the SNH Data Table from URL Definition widget as well as the underlying core SNH Data Table widget. In the User Directory, the Department column and the Location column reference links are mapped to two other pages that were built using the SNH Data Table from JSON Configuration widget, and clicking on the value in one of those columns should test out both the reference link handling and that other wrapper widget.

Department Roster page

So far, so good. Clicking on a Location value should test out the reference link handling from this wrapper widget, and also bring up yet another page using the second of the three wrapper widgets.

Location Roster page

Once again, everything seems to be behaving as it should using the two wrapper widgets tested so far. The third wrapper widget, the SNH Data Table from Instance Definition widget, is not used in the User Directory, but we have other test scenarios set up for that one. Before we move on, though we can go ahead and test one more thing while we are working with the User Directory: conditional icons. In the User Admin perspective, there is an icon defined to edit the user’s data. We can add a quick condition to that icon configuration and see how that works out. Just for testing purposes, let’s try the following expression:

item.department.display_value == 'Sales'

If that works, the edit icon should only appear for users who are assigned to the Sales department.

User Directory User Admin perspective with conditional icon

Well, that seems to work as well. Good deal. While we are here, we might as well click on the icon and see if the button click handling works as well as the reference link handling that we tested earlier.

User Profile edit page

And it would seem that it does. That’s about all that we can squeeze out of the User Directory, but we still have a lot more to test, including the third wrapper widget and the other new feature, the clickable aggregate columns. Plus, we still have to do regression testing for bulk actions and clicks that result in a modal pop-up box instead of branching to a new portal page. That’s a lot to get through, so let’s keep plowing ahead.

Our third aggregate column test page was built on the SNH Data Table from Instance Definition widget, so let’s pull that guy up and see how things look.

Aggregate Column test page #3

Well, that all seems to work, and the Network group has two Incidents, so we just need another page to which we can link to display those Incidents. That’s easy enough to do with yet another aggregate column test page using the SNH Data Table from Instance Definition widget, a table name of Incident and a filter of active=true^assignment_group={{sys_id}}.

Aggregate Column test page #5

So all of three of the wrapper widgets seem to work, which by default tests out the core widget, and direct links from reference columns, buttons, and aggregate columns all navigate to the appropriate pages. That just leaves bulk actions and modal pop-ups to be tested, both of which will require companion widgets to listen for the associated broadcast messages. For that, we will have to hunt down or create some companion widgets for testing purposes, which might get a little involved, so let’s jump into that next time out.

4 thoughts on “Refactoring the SNH Data Table Widget, Part III”

  • Conan Lloyd says:

    This is awesome work and I would love to use it!

    I like to think I’m a decent coder ands somewhat intelligent, but I am LOST!!! I’ve imported your update sets into 2 of my Rome instances and run into a couple issues, primary of which is that I cannot add a table when using the Content Selector Configurator. I click the add a table button and the modal displays but there is no where to select a table.

    Let me take a step back, since I’m a visual learner. My use case is to have a data table showing KB articles that match this filter, (kb_knowledge_base=9486f9011b3a4cd45947748edc4bcbfa^workflow_state=published^valid_to>=javascript:gs.beginningOfToday()), and provide an subscribe or unsubscribe button on each row. I think your data tables are a perfect solution, but I can’t seem to figure the pieces out. Any chance you could help this old man with a rough example that I can “go to school” on?

    • Conan,
      So nice to hear that you find this useful. So sorry that you are having difficulties, though — I hate it when that happens! Let me ask you this: when you use the configuration editor on any of the existing configuration files in the bundle, do you have the same issue with the New Table button? I am assuming that you are attempting to create a new configuration file, so I am just curious to know if the issue is only present for a new one, or if the same thing happens with an existing one. I will do a little testing myself and see if I can reproduce the issue that you are having. Thanks for the feedback.

    • By the way, if there is an issue with the editor, you can always manually create a Script Include file for your use case by cloning one of the sample configuration files and then editing the contents. Here is one that I was able to create using the editor in my instance that might provide a good starting point (by the way, I did not have the issue with the Add Table pop-up that you described):

      var DeleteMe = Class.create();
      DeleteMe.prototype = Object.extendsObject(ContentSelectorConfig, {
      initialize: function() {
      },

      perspective: [{
      name: 'all',
      label: 'All',
      roles: ''
      }],

      state: [{
      name: 'all',
      label: 'All'
      }],

      table: {
      all: [{
      name: 'kb_knowledge',
      displayName: 'Knowledge',
      all: {
      filter: 'kb_knowledge_base=9486f9011b3a4cd45947748edc4bcbfa^workflow_state=published^valid_to>=javascript:gs.beginningOfToday()',
      fields: 'number,short_description',
      aggarray: [],
      btnarray: [],
      refmap: {},
      actarray: []
      }
      }]
      },

      type: 'DeleteMe'
      });

      Also, an image of the modal pop-up that is not working might help me better understand what might be happening there … thanks!

      • Conan Lloyd says:

        Thanks for the reply! I did create one by editing an existing and then doing an insert and stay, but would like to see how the configurator works.
        I don’t see an easy way to attach a screenshot here but would be happy to send you one if you want to send a contact email to my email. (I promise not to abuse it)

Comments are closed.