“It’s really complex to make something simple.”
— Jack Dorsey
Last time, we wrapped up an initial version of the storefront and released a new Update Set in the hopes that a few folks out there would pull it down and take it for a spin. While we wait patiently to hear back from anyone who might have been willing to download the new version and run it through its paces, let’s see if we can’t add a little more functionality to our shopping experience. The page that we laid out had a place for two widgets, but we only completed the primary display widget so far. The other, smaller portion of the screen was reserved for some kind of search/filter widget to help narrow down the results for installations where a large number of applications have been shared with the community. Adding that second widget to the page would give us something like this:
Rather than have the two widgets speak directly to one another, my thought was that we could use the same technique that was used with the Configurable Data Table Widget Content Selector bundled with the SNH Data Table Widgets. Instead of having one widget broadcast messages and the other widget listen for those messages, the Content Selector communicates with the Data Table widget via the URL. Whenever a selection is made, a URL is constructed from the selections, and then the Content Selector branches to that URL where both the Content Selector and the Data Table widget pull their control information from the shared URL query parameters. We can do exactly the same thing here for the same reasons.
For this initial attempt, I laid out a generic search box and a number of checkboxes for various states of applications on the local instance. To support that, we can use the following URL parameters: search, local, current, upgrade, and notins. In the widget, we can also use the same names for the variables used to store the information, and we can populate the variables from the URL. In fact, that turns out to be the entirety of the server-side code.
(function() {
data.search = $sp.getParameter('search') ? decodeURIComponent($sp.getParameter('search')) : '';
data.local = $sp.getParameter('local') == 'true';
data.current = $sp.getParameter('current') == 'true';
data.upgrade = $sp.getParameter('upgrade') == 'true';
data.notins = $sp.getParameter('notins') == 'true';
})();
And here is the HTML that I put together to display the information.
<div class="panel">
<div class="row">
<div class="col">
<p> </p>
</div>
</div>
<div class="row">
<div class="col">
<input ng-model="c.data.search" name="search" id="search" type="text" class="form-control" placeholder="🔍"/>
</div>
</div>
<div class="row">
<div class="col">
<input ng-model="c.data.local" name="local" id="local" type="checkbox"/>
<label for="local">${Local}</label>
</div>
</div>
<div class="row">
<div class="col">
<input ng-model="c.data.current" name="current" id="current" type="checkbox"/>
<label for="current">${Current}</label>
</div>
</div>
<div class="row">
<div class="col">
<input ng-model="c.data.upgrade" name="upgrade" id="upgrade" type="checkbox"/>
<label for="upgrade">${Upgrade Available}</label>
</div>
</div>
<div class="row">
<div class="col">
<input ng-model="c.data.notins" name="new" id="new" type="checkbox"/>
<label for="notins">${Not Installed}</label>
</div>
</div>
<div class="row">
<div class="col text-center">
<button ng-click="search()" class="btn btn-primary" title="${Click to search the Collaboration Store}">${Search}</button>
</div>
</div>
</div>
To format things a little nicer, and to kick that little magnifying glass search icon over to the right, we also need to throw in some CSS.
.col {
padding: .5vw;
}
label {
margin-left: .5vw;
}
::placeholder {
text-align: right;
}
There is one client-side function referenced in the HTML for the button click, and that’s pretty much all there is to the widget’s Client script.
api.controller = function($scope, $location) {
var c = this;
$scope.search = function() {
var search = '?id=' + $location.search()['id'];
if (c.data.search) {
search += '&search=' + encodeURIComponent(c.data.search);
}
if (c.data.local) {
search += '&local=true';
}
if (c.data.current) {
search += '¤t=true';
}
if (c.data.upgrade) {
search += '&upgrade=true';
}
if (c.data.notins) {
search += '¬ins=true';
}
window.location.search = search;
};
};
The search() function builds up a URL query string based on the operator’s input and then updates the current location with the new query string, essentially branching to the new location. When the new page loads, both the search widget and the storefront widget can then pull their information from the current URL. We can test all of this out now by saving the new widget, pulling up our collaboration_store page in the Service Portal Designer, and then dragging our new widget onto the page in the space already reserved for that purpose.
With that completed, we can now try out the page and see that entering some data and clicking on the Search button actually does reload the page with a new URL. However, at this point the content of the primary page never changes because we have yet to add code to the main widget to pull in the URL parameters and then use that data to adjust the database query. That sounds like a good subject for our next installment.
