“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein
So, I came up with a way to search all of the places in which a chunk of code might be hiding, but to get the results, I have to run it as a background script and parse through the resulting JSON object. I need something a little more user-friendly than that, so I am going to build a Service Portal widget that takes a user entered search string, makes the call to the search script, and then formats the results a little nicer. Then I am going to add an item to the Tools menu that I created for my sn-record-picker tool that will bring up this new widget. This way, all I will have to do is click on the menu, enter my search terms, and hit the button to see the results.
The first thing that we will need to do is to lay out the page. Nothing exciting here: just an snh-form-field text element for capturing the input, a submit button, and a place to display the results, all wrapped up in an snh-panel. It’s a relatively small snippet of HTML, so I can reproduce the entire thing here:
<snh-panel class="panel panel-primary" rect="rect" title="'${Script Search}'">
<form id="form1" name="form1" novalidate>
<div class="row">
<div class="col-sm-12">
<snh-form-field
snh-model="c.data.searchFor"
snh-name="searchFor"
snh-label="What are you searching for?"
snh-help="Enter the text that you would like to find in a script somewhere in the system"
snh-required="true"
snh-messages='{"required":"Please enter what you would like to find"}'/>
</div>
</div>
<div class="row">
<div class="col-sm-12" style="text-align: center;">
<button class="btn btn-primary" ng-disabled="!(form1.$valid)" ng-click="findIt()">${Search all scripts}</button>
</div>
</div>
</form>
<div class="row" ng-show="c.data.result">
<div class="col-sm-12" ng-show="c.data.result.length==0">
<p>${No scripts were found to contain the text} <b>{{c.data.searchFor}}</b></p>
</div>
<div class="col-sm-12" ng-show="c.data.result.length>0">
<table class="table table-hover table-condensed">
<thead>
<tr>
<th style="text-align: center;">${Artifact}</th>
<th style="text-align: center;">${Table Name}</th>
<th style="text-align: center;">${Table}</th>
</tr>
</thead>
<tbody>
<tr ng-repeat="item in c.data.result">
<td data-th="Record"><a href="{{item.table}}.do?sys_id={{item.sys_id}}" title="Open {{item.name}}">{{item.name}}</a></td>
<td data-th="Table Name">{{item.tableName}}</td>
<td data-th="Table">{{item.table}}</td>
</tr>
</tbody>
</table>
</div>
</div>
</snh-panel>
There is an ng-click on the submit button that will call a function on the client-side script, so now is as good a time as any to build that out. Again, there really isn’t all that much code to see here:
function ScriptSearch($scope, $location) {
var c = this;
$scope.findIt = function() {
$location.search('search', c.data.searchFor);
};
}
You may notice that we don’t actually search for the script at this point; we just branch to a new location. This is a little trick that I stole from my Configurable Data Table Widget Content Selector, which also just takes user input and uses it to build a new URL, and then takes you to that URL where the search actually takes place. The reason for that is so that all of the user input is a part of the page URL, which means that if you drill down and follow any links on the page, when you come back, all of your original search criteria is still intact and the page comes back just the way that you left it. This works really slick in the Service Portal; it’s just really too bad that I didn’t have the same experience when I launched this widget inside of the main UI. But, we’ll deal with that later.
Right now, it’s time to tackle server-side script, and once again, you aren’t going to see much here in the way of actual lines of code:
(function() {
data.searchFor = '';
data.result = false;
if ($sp.getParameter('search')) {
data.searchFor = $sp.getParameter('search');
data.result = new ScriptUtils().findInScript(data.searchFor);
gs.setReturnURL('/$sp.do?id=script_search&search=' + data.searchFor);
}
})();
Basically, we start out by setting the default values for our two data properties, and then if there is a search parameter on the URL, we override those values with the search term and the results of running that search term through our script searcher. That last line was my attempt to preserve the URL so that when I clicked on an item to go look at it, my results would still be displayed when I returned. Unfortunately, that didn’t work, either. One day, I will figure out how to fix that, but for now, each time I leave the page, I have to search all over again to get my results back. Not the way that I want it to work, but at this point, I can live with it.
That’s about it for all of the various parts. Pretty simple stuff, really. Here’s what it looks like in action:
All in all, I like the way that it turned out, although it really annoys my sense of The Way Things Ought To Be when I click on one of those items and then come back and find that my search results are all gone. That’s just not right. One day I am going to fix that, but until that day comes, here is an Update Set for anyone who wants to play along at home, and maybe even take care of that little annoyance for me!
