Service Portal Form Fields, Part IX

“I do one thing, I do it very well. And then I move on.”
Charles Emerson Winchester III

Generally speaking, I try not to tinker. Once an idea has been turned into an actual functioning reality, I like to set that aside and move on to other ideas. But there’s always that one little thing that you realize that you could have done better, or just differently, and there is this constantly nagging temptation to go back and fine tune things just to make them a wee bit better. I prefer not to give in to that temptation and just press forward towards other aspirations, but occasionally there are some things that you just can’t let go. So here we are …

I started out thinking about drafting some actual instructions, and identifying which attributes are mandatory and which are optional. Then I realized that there really isn’t any code that requires you to include any attribute at all. Things just won’t work if you don’t get it right. I don’t really like that, so I added a few lines to put out a configuration error instead of making a failed attempt to render HTML in the event that you left out a critical attribute. That turned out to be a relatively simple thing to do:

if (!name) {
	htmlText = configurationError('Attribute snh-name is required');
} else if (!model) {
	htmlText = configurationError('Attribute snh-model is required');
} else {
	...

Of course, once you crack open the code, you’ve now opened the door to squeezing in all of those other little tweaks and tidbits that you thought about doing earlier but never got around to actually putting into place. I don’t like having to specify things if it isn’t absolutely necessary, which is why I kept looking for a way to avoid having to specify the form name. It is also the reason why I default the the type value to text. The label is another thing I didn’t think you should have to specify, as you could use the name for that purpose, if no label was provided. I never put that in there, though, so since I was already opening up the code for another version, I went ahead and threw that in there as well.

var label = attrs.snhLabel;
if (!label) {
	label = nameToLabel(name);
}

Something else that I had been contemplating was throwing in an SMS link icon for cell phone numbers in addition to the link icon that I had put in to place a call. A couple of teeny little wrinkles popped up in that exercise, but nothing too awfully exciting really. For one, I didn’t want that showing up for land lines, so I ended up basing its presence on the label, and only had it show up if the label contained the word cell or mobile. The other thing that cropped up was that AngularJS converted the sms: protocol to unsafe:sms: for some reason, and it took a little while to figure out how to stop that from happening. Apparently, you have to add this line of script outside of your widgets and providers:

angular.module('sn.$sp').config(['$compileProvider',function( $compileProvider ){ 
        $compileProvider.aHrefSanitizationWhitelist(/^\s*(https?|ftp|mailto|file|sms|tel):/) ;
}]);

I’m not all that clear on how all of that works, but it does work, so I’m good. All together, it’s not all that much of an improvement, but it’s different, so I guess we’ll call this one v1.2. Now I just need to put it all together into another Update Set for anyone who might want play around with it on their own.

3 thoughts on “Service Portal Form Fields, Part IX”

  • Jeff Chilton says:

    Any chance that you will release a version that supports the same choicelist options as the stock sn-choice-list? I like what you have done, but I need to pull my select options from a variable and this only seems to work if you place a hard-coded JSON object array directly in the choices attribute.

    • Glad to hear that you like it so far. Thanks for the tip on the missing functionality. Keep checking back … maybe we will fill in that hole one day and toss out a version that will address that issue.

Comments are closed.