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:
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.
- 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!
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  
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.
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.