Get started using web API’s – Luas Forecasting API Part Three

After much struggles, see the previous entry for the history up til now, the responseText message was successfully parsed and the information populated on the page:

Luas Arrival Time

Luas Test App

Some of the pitfalls:

  • Response message was a string which wouldn’t yield to any XML extraction methods. That was sorted once parsed to XML. (Response methods for XML didn’t yield anything or issues further along made me dismiss it altogether.
  • It was impossible to extract any data, attempts yielded
    • XML Object Element.
    • HTML Object Element.
    • Null.
  • Xpath was used to get at the data but still no luck (some remnants can be seen as code or comments).
  • API was down for maintenance which didn’t allow much progress.

There were myriad of explanations and convoluted methods to get the data but the issue lay in that the information needed was in the attritbutes and not in the nodes. I’ll do a clearer, indepth write up of all the steps taken to create this but for now this shall be parked.

Some improvements I’m planning on however include:

  • Automatic updating of the page when the response refreshes.
  • Selecting stops by name and whether inbound or outbound.

Stay tuned for that and more!

Get started using web API’s – Luas Forecasting API Part Two

Continuing on from the last post – Get started using web API’s – Luas Forecasting API Part One , there was a slight issue I ran into. This was resolved after several commits where I’d tried to see if I could print out the response regardless of the response status. However those failed and can be seen in my commits [1] [2]

The issue was that I couldn’t get any response message back once the code was hosted on github pages – It worked perfectly on my machine (hey oh). It would just default to the else condition in the httpRequest’s onreadystatechange update – i.e. the assigned function alertContents() would return the message if the response wasn’t in a readyState of ‘DONE’ and status wasn’t 200.

else {
 alert('There was a problem with the request\n');
 alert(httpRequest.responseText); // added an alert to see what message 
                                  // being returned - there was none.

The responseText from the httpRequest didn’t contain any message to help troubleshoot. The problem was later pinned down to a mixed content issue – it’s one where the calling code requests a non secure request ‘http’ and the API would send back or expect a request call to be secure and hence return a secure response.

With that sorted, the next step still remains: Extract information from the xml response and update the webpage. For now here’s the page, click the button to get a raw response message in all its glory.

Get started using web API’s – Luas Forecasting API

My JavaScript excursions have taken a damper as of late. Without much digression, the next mini project I want to tackle is how to consume an api and present it on a page. I’ve been having a bit of internal conflict if I should conduct this on GitHub or codepen and came to the conclusion that i’ll do it on both – first attempt on GitHub and a cloned, improved version, on codepen.

For this tutorial, of sorts, will include the following:

  • Consume the public Luas API
  • Extract relevant information and display on a page

At this point it will only be for a specific location and inbound shuttles. At this stage the HTML & CSS have been setup, as well as the AJAX script to call the Luas Forecasting API.

The API only seemed to show tabular information and not much of explanation or examples are available, bar one on the page for the aforementioned API. It seemed to be only displaying the current status, however, when it was retrieved, the response contained all the relevant information that is needed i.e. the stop name, inbound/outbound and luas arrival times.

Luas Forecasting API response message

Luas Forecasting API response message XML

The next step will be to parse the XML received and push the relevant info to the page. The code so far is available on GitHub. One issue is the GitHub page the AJAX call refuses to play nice. I’l have to look into that as well the next time around, stay tuned!


Javascript functions

JavaScript allows numerous ways in which functions can be created and invoked.

Named functions

These have a name associated with them

function nameOfFuction(){ // code goes here; }

Assigned functions

These are usually named or anonymous functions which are assigned to a variable

var someName = function someFunction() { // code; };
// invoking the function like so

In this case the function is considered a statement so needs to have a semicolon unlike a typical function declaration.

Anonymous functions

These are functions without a name and are most suited for assignment to other variables, in fact the previous function type would be far better using anonymous functions.

var someName = function someFunction() { // code; };
// invoking the function like so

Another way anonymous functions can be used is by having it as the return value of another function

function mainFunction(param1, param2){   // code   return function(){
      // code 

In order to utilise this, the main function itself will NOT work as it will only return the function statement it contains within its body. It is returned in a structure known as a closure:

 // This will return anonymous function from the main function body
mainFunction(paramValue1, paramValue2);
( function() { //code } )

It can, however, be assigned to a variable and thus run like an assigned function

var functionRunner = mainFunction(paramValue1, paramValue2);

or it will need to have a pair of parenthesis added to the end of the function call if it is to be invoked like a standalone function, which will not be returning a function.

mainFunction(paraValue1, paramValue2)();

What is happening is that  the returned anonymous function will get the ‘()’ and be invoked like a regular function call. This is known as immediate function invocation.

A brief intro to Node.js

This is a topic I’ve been meaning to approach for a while now. As it happens, one of my college courses – Web Applications – requires a project built using Node.js, so what better time to tackle this.

I had mentioned Node.js in a previous post, where I was talking about the various environments JavaScript can be run in. This post won’t go into the history or specifics of Node.js; the main exercise will examine the various items found in the sample code for creating a simple Node.js server – which will explore and detail node specific aspects as well as JavaScript patterns used. The code can be found on the About page on the Node.js site:

const http = require('http');

const hostname = '';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World\n');

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);

Play by play

The very first line of code, allows us to import the module ‘http’.

const http = require('http');

This is the implementation method that is specified in CommonJS, which is an ecosystem for JavaScript outside the browser. This is a synchronous system which allows importing of modules or files; since everything will be on the server side. This allows us to import the module http.

The next two lines set the IP address of the localhost (the machine you are currently on) and the port to listen to for incoming requests.

const hostname = '';
const port = 3000;

Immediately following that, the createServer() method is called on the http instance we created on the first line. Which is then assigned to a constant called server.

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World\n');

This is passed a call back function with two parameters and uses an arrow function (read more about it here [1] [2]). This createServer() method will be invoked by an incoming event, in this case web requests. The req parameter will contain all the incoming request’s details. The res parameter will handle the response which will be sent out. In this case it’s setting its statusCode to 200, which signifies that the request was handled successfully. After which the response’s header information is set to indicate it’s content which in this case is plain text. And finally some plain text output is shown while closing the response – this will be displayed in the browser.

The final section of the code, referencing the server which points to the http.createServer() call, is set to listen on the port and host IP address set above.

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);

The arrow function will display the message indicated while the server is running in the node.js environment giving us a visual that things are working.

There you go, this was just a quick run down to help try and elucidate, both for me and anyone reading this, what is happening within this simple node.js server code. Stay tuned for more practical topics on the matter.

Simple JavaScript Timer: Part III

The remaining requirements from the last session are:

  • Refactoring the two buttons to just one for starting/stopping the timer
  • Being able to capture snapshots of the timer countdown on a button press.
  • Clearing the snapshots and resetting the timer on another button press.

Refactoring the two buttons to a single one which would handle the starting and stopping of the timer proved to be tricky. For the single buttons Start and Stop a reference to the calling object itself was passed to the function and based on the innerHTML of that object, the button, the code would start or stop the timer.

Button innerHTML with JavaScript

JavaScript code to specify which button is being clicked

When only one button was present, there was nothing that could be used to identify what ‘state’ the timer, by extension the button, was in. Tried one or two ways to sort this but most of them resulted in the single button functioning once to start/stop the timer but after that it wouldn’t function at all.

What finally did it was the creation of a Boolean to keep tabs of whether the button was clicked. Simple but boy did it take some time getting to it. [see commit]

JavaScript button handler code

JavaScript button handler

With that out of the way the only thing left to do was to capture the counter values and show them beneath the actual counter and reset the captured values and timer count. This was simple enough and only required adding to the innerHTML of the display area and clearing them. [see commit]

One final item remaining was to enable key presses to activate the same functions as the button presses. These were:

  • ‘s’ to start and stop the timer
  • ‘t’ to record the times
  • ‘r’ reset the recorded times and timer

This presented some challenges as I wasn’t too sure how the code would be invoked from a separate script file. I thought it would have to go in the actual HTML document. But referring to the document element from the script file and adding an event listener to it did the trick.

Document event listener setup

Document event listener setup

From there it was just a simple callback function, part of which can be see above, with the event object passed to it from which the keypresses could be retrieved.

And there you have it, another successful simple  project completed. You can see it in action here

There was one final issue, this time with Github. You can see the code at various iterations of the work in progress, however the final Github page only shows the final results.

Catch up with the initial posts about this piece:


JavaScript callback functions

Another primer, this time on callback functions.  Call back functions are basically a function that is passed as an argument, or included wholly as in the case of anonymous functions, in another function’s call. It hails from, wait for it… functional programming.

One way of understanding how callbacks function *pardon the pun*, is based on one form of creating a function in JavaScript:

var someFunction = function functionName() {  // code goes here}

This is known as a function expression, whereby a function is declared and assigned to a variable. [1] Now, someFunction can be used to invoke functionName() just by calling it similarly to how a function would be called i.e. someFunction();

In a callback function pattern, in one scenario, a named function which has already been declared is passed as an argument in another function.

function gradeBoost(x){ // call back function
   return x += (x *= .15);

function bonusQuestion(receivedMarks, callback){ // uses callback function
  return callback(receivedMarks);

var finalMarks = bonusQuestion(45, gradeBoost));

So, in the example above, gradeBoost is the callback function. In bonusQuestion, the second argument ‘callback’ is set to receive (be assigned) the callback function, gradeBoost, similar to the first code explanation block above this example.

Within the body of bonusQuestion, the assigned function is setup based on the parameter list of the gradeBoost callback function. The result being when bonusQuestion is called and passed in gradeBoost as the callback function argument, gradeBoost returns the result of the calculation to the bonusQuestion function call.

This is in essence how callbacks are cast and called. For some more applications of callback functions see the post on Asynchronous JavaScript.

Handy little methods for Xrm.Page calls in browser for Dynamics CRM

Based on the last post about retrieving Microsoft Dynamics CRM record based information from the console ‘Dynamics CRM – Access GUID from the browser console‘, I thought I write up some other useful bits that can be used to get information in a pinch.

Most of these have be run from the viewport where the record in question is open, unless otherwise stated.

Get an entity’s origin


This is particularly handy when you want to know the logical name to work with programmatically. All this without having to open up the solution or form and plow through a few forms and several clicks.

Get logical name for controls in the controls collection


The controls collection is a child of the ui object, which itself is a child of the Xrm.Page object. [See the visual layout on MSDN]. The index allows retrieval of control items as they occur on the form.

Get logical name for control based on display name


Now there are no direct method calls, that I found or aware of, that could get you the logical name for a field based on its display name. Which is a big shame because that would be a very useful one.

Now this might be somewhat tedious based on what wants to be achieved, and most definitely based on the number of fields on the form, as the user will have to randomly call the setFocus() method on a guess of where the control might be in the index based on position i.e. if the field is placed in the middle of the list of fields, chances are the index will be roughly half of the length of the count of fields.

But once the focus reveals the field that the user is interested in, the previous method getName() can be used to retrieve the logical name using that same index.


These calls are part of the Xrm.Page model which can be referred to on the MSDN site. However, they can be utilized for quick little views at relevant information via the browser’s console.

JavaScript: Asynchronous Programming Primer

Some aspects of JavaScript are well known, or well loathed, mostly because it’s only partially understood. Some of these include that JavaScript is an interpreted language, which is not entirely true, which we’ll save for another day. Another is that JavaScript is a single threaded language, which is true but there are structures which allow more than a single thread to operate.

A city called asynchroni… city

Asynchronous programming allows multi-threading via Web API’s (such as event handlers) that handles processes and return tasks to the browser separately from the main thread.

The cycle follows that when a function or other code is encountered, it is placed on the Call Stack and the stack at this point is unavailable till this code is executed. The Call Stack is the data structure that handles function calls in the order that they were executed, i.e. first in, last out. This stack is the main thread that JavaScript runs on in browser. If, however, an asynchronous function is encountered, the code is deferred to a non Call Stack process to handle,

These other processes run the code, which are sent to it as callback functions, whose results are then queued in the Event Queue. This is eventually passed back to the Call Stack when it is empty. A common Web API that processes such asynchronous calls are Timers, these include:


The setTimeout() method can be used to put a task on the event queue.  The method takes a callback function as the first argument and the amount of time to wait as the second argument. The time value is numeric in milliseconds. e.g. 500, 1000 which equates to half and one full second,


This is similar to the setTimetout() method however, the call back function will be called non-stop after each time value period lapses.

Stopping Timers

Each method above can be stopped using the related stopping methods:

  • clearTimeout()  // for setTimeout()
  • clearInterval()   // for setInterval()

When the respective timer events are created, it returns a numeric id which can be stored in a variable and then passed on to the methods indicated. This allows targeting a specific timer instance to be stopped.


Asynchronous programming allows processes, which would otherwise tie up the browser and make it unusable to another handler and return the results to the main thread. Thus allowing the application question to be efficient and responsive.

This is just a small primer on the asynchronous capabilities of JavaScript on the browser side. Stay tuned as more write ups will focus on this topic and related areas.