Generate an Angular Service from a Script Include

I figured I would dedicate Fridays to Angular and Jelly articles, first up here is generating an Angular Service automatically from a Script Include.

You might be tempted to just put GlideAjax calls right within your Angular Controller but that’s bad.  It clutters your controller and if you ever need to use that same function you would need to copy and paste that code.  On the other hand if all you need to do is create a Service that calls a Script Include it makes no sense to create UI Scripts for each that all essentially do the same thing.  To me this is not a problem but a chance to simplify creation of these Services by using a Processor.

To start I need to programatically extract the functions and parameters from a given Script Include.  Initially I thought a Regular Expression might work but it’s not a good solution.  Instead I chose to use Esprima to generate an Abstract Syntax Tree (a sort of representation of the code as a tree) and use that to find functions and parameters.

Esprima (http://esprima.org) actually loads right into ServiceNow as a Script Include without any issues.   Once loaded you can just include that Script Include and create syntax trees from any code in the system.

I created a Processor which generates an AST from a Script Include.  I look through the AST to find the main object (the one that is assigned to a variable of the same name as the Script Include) and then looked through that object for functions.

Each function not prefixed with _ is expected to be a public function and will be added to the returned Angular Service.

Within the body of that function if I find any assignments that have “getParameter” in the expression I pull out the name and use that as a parameter for the Angular Service method.

I also included a function to parse the XML response that is automatically called when the response comes back from ServiceNow.

Now for any Script Include, which extends AbstractAjaxProcessor, I can link to my processor which will generate an Angular Service with all the functions from the Script Include automatically.  I can inject that service into my apps controllers and call the functions as if they were on the client side.

Instead of using GlideAjax I use the Angular $http provider which returns a promise object.  So when you use the result of the function call you must do so through a `then` function.  Check out the examples below to see this in action.

github:gist https://gist.github.com/salcosta/c68686e4e82c237dd627


Example

The Angular Service that should be generated from this Script Include should have 2 methods with one accepting `sysparm_sys_id` as a parameter.

var IncidentTest= Class.create();

IncidentTest.prototype = Object.extendsObject(AbstractAjaxProcessor, {

getIncidents : function(){
var sys_id = this.getParameter("sysparm_sys_id").toString().toString();

return sys_id
},

getIncidents2 : function(){
return "test"
}

});

Here is the example output that would be generated.


angular.module('IncidentTestService', []).factory('IncidentTestServ', ['$http', function($http) {

return {
config : { headers: {'Accept' : '*/*', 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8','X-UserToken': g_ck } },
url : 'xmlhttp.do',

getIncidents : function ( sysparm_sys_id ){
var data = 'sysparm_processor=IncidentTest&sysparm_name=getIncidents&ni.nolog.x_referer=ignore&x_referer=home.do&sysparm_sys_id=' + sysparm_sys_id + ''

return $http.post( this.url , data , this.config ).then( getAnswer );
},

getIncidents2 : function ( ){
var data = 'sysparm_processor=IncidentTest&sysparm_name=getIncidents2&ni.nolog.x_referer=ignore&x_referer=home.do'

return $http.post( this.url , data , this.config ).then( getAnswer );
}
}

}]);

Here’s a sample usage in a UI Page.

HTML

<script src="IncidentTest?ng-service"></script>

Script

angular.module("Inventory",['InventoryCtrl','IncidentTestService']);

angular.module("InventoryCtrl",[]).controller("InventoryController", ['$scope', 'IncidentTestServ', function($scope, IncidentTestService){
IncidentTestService.getIncidents("Test").then(function(res){
console.log(res)
});
}]);

ServiceNow Coding Style Guide Part 1

I thought I would kick of this new blog with a topic that is very important to me,  Coding Style in ServiceNow.  Here I will present a short list of rules and principles to guide your coding.

Following this guide will make your code more readable which will make maintaining the code much easier.  That means less time trying to decipher your or co-workers code and lower costs to maintain code.  This is true of any code base but especially in ServiceNow where the developer ecosystem is so varied.

The end goal is to have all code appear to be written by a single person.

Once a good track record can be established on following these practices then you can start to introduce higher level concepts and principles.  More on those in future articles.

Personally, I disagree with long style guides and best practices documents.  If there are too many rules to start it is impractical for new developers to follow them all.  My approach is to start with the fundamentals.  Once they are mastered then you can layer in more advanced practices.  So for now I am keeping the list short. (It should fit on an index card)

Naming
Functions should be named like verbNoun, using camel case. This will make it easier to remember as well as forcing the function to perform a specific purpose.

Variables should not have abbreviations, ever.  It is preferable to use camel case when creating variables although underscores have started to be used instead.  It does increase readability but most existing code will not follow this.

Classes should always be camel case with the first initial capitalized.

Constants should be all upper case.

All record names should follow a convention.  I prefer Prefix – Script Name, where the prefix is the company name or application name.  This is applicable only where the record name is not the script name such as on Business Rules and Client Scripts.

Script Includes should follow the same convention as classes.  UI Scripts should be all lower case using underscores to separate words.

Formatting
There are two options for brackets, same line or not.  I prefer same line.  As long as you are consistent it is a matter of opinion

Whitespace should be used liberally to increase readability.  I favor using spaces within parentheses.  Line breaks to separate blocks of code within functions and two line breaks between functions.

Indentation should be 2 or 4 spaces but be consistent.

Semicolons should always be used.

Commenting
By all means, if you feel your code is to complicated use comments to clarify, but before you do that ask, “Can I rewrite this to make it clearer?”  If the answer is yes, rewrite the section and see if the comment is still necessary.  The goal is for the code to document itself.

Odds and Ends
Always use === instead of == to compare values.  This will prevent accidental coercion of variables.

Try and use ‘ instead of ”

Avoid ternary operators

Avoid eval

Principles
Don’t Repeat Yourself.  If you find yourself writing the same code over and over generalize it and move it to a separate function.

Never just copy and paste code.  Always rewrite it and try to understand line by line what it’s doing.  While it’s tempting to just inject a bunch of functionality, that is not going to help if there is an error or you need to modify the code.

Try to keep your code separated by intention.  For instance don’t have a single function that does a database call and then immediately updates the UI.  This is called Separation of Concerns and is the basis for other more specific principles like MVC.  Separated code will make it easier to update and reuse.

Finally, care about your craft.  Your code will likely never hang in a museum but the functionality that you are building matters to your users and it should matter to you as well.

Bonus Cheat Sheet!

Cheat Sheet
Coding Style Guide Part 1 Cheat Sheet

 

Reboot

After a ton of issues with the old site I have decided to reboot on WordPress 4.0.  This is going to be a lot cleaner and a lot easier to manage.

Most of the old content is no longer useful but what is I will selectively import and update.

In addition I will be bringing new content featuring tutorials on JavaScript and web development, integrations, best practices, administration tips and tricks and the latest ServiceNow news.

Thanks for visiting and check back often!  New content will be published weekly.

Visit Us On Twitter