Made in USA: Enterprise Application Services

Archives by Category | JavaScript | Ayoka Systems Made in USA

How to Develop Websites Using ASP.NET

January 28, 2014

ASP.NET is great for building standards-based websites with HTML5, CSS3, and JavaScript. ASP.NET supports three approaches for making web sites. ASP.NET Web Forms uses controls and an event-model for component-based development. ASP.NET MVC values separation of concerns and enables easier test-driven development. ASP.NET Web Pages prefers a single page model that mixes code and HTML markup. You can mix and match these techniques within one application depending on your needs – it’s all One ASP.NET.

To create a file system Website
1. Open Microsoft Visual Studio 2010 or Microsoft Visual Web Developer Express.
2. On the File menu, click New WebSite.
3. Under Installed Templates, click Visual Basic or C# and then select ASP.NET Web Site.
4. In the Web Location box, select File System, and then enter the name of the folder where you want to keep the pages of your Web site.
5. Click OK.

Here is a link to some free ASP.NET templates

How Has Life Changed on the Front Lines of User Experience (UX) Design?

October 15, 2013

As a front-end web developer these days it is vital to possess a very robust skill set to be effective in the market place, and to pull your weight on a team. A lot of people think that the User Interaction and User Experience (UI and UX respectively) stuff is just making things look pretty and therefore, is not as complex as the server side of things. This could also lead someone to the conclusion that if it is not as complex as the back-end then it must not be a vital to a project. In some projects that may be the case, but it really comes down to how much “Company X” has invested in the project and what the return on that project needs to be.

Web design, HTML 5, Javascript

The UI is the first element that a User interacts with. It’s the suit and tie, smile, and handshake that will welcome them and interact with them during their stay. The common User has no idea that there is a difference between different programming languages, let alone different types of web development. A skilled front-end developer or web designer will know HTML5, CSS3, JavaScript, JQuery, Photoshop and Illustrator (or their equivalent), along with a handful of plug-ins to make a project run smoother.

Often the front-end comes in at the latest stage in development so these key people need to know how to trouble shoot issues to iron out the wrinkles and get it ready for “shipping.” Designing the UI and UX for a product whether it is a website, camera, chair, or ballet is a job that requires real understanding of the target User and the desired result.  Making a product that is both intuitive and robust is a very complicated undertaking and requires much planning and experimentation. Sometimes taking something that has been created on the back-end and making it function and interact naturally with the User can be a back-and-forth process of try, fail, and succeed until finally it works.  It’s about getting creative and breaking barriers to introduce new, fun, and interactive experiences for the User. A good web designer will be there from the beginning to the end of the project; planning and drawing up mock-ups, making sure the design is set in motion, getting their hands dirty and coding, and cleaning up any trouble that will naturally come along with any project. In other words they are like the Marines, “First ones in and last ones out!” Well maybe not that drastic or dangerous but the point is there.

What is AJAX?

June 16, 2009

The word AJAX is thrown around so often that it is hard to understand what AJAX really is. AJAX itself is not that new of a technology, but recent JavaScript libraries have made it a very popular tool. This has even lead to the widespread use of the term (inappropriately in some cases).

In this post, I will go over the high-level concept of Asynchronous JavaScript and XML for those who just want a better understanding. Then I will delve into the low level technical overview of how AJAX works for those who are interested.

Let’s first break down the acronym AJAX.

Asynchronous: Non-blocking, not synchronous

JavaScript: Also known as ECMA script (and has absolutely NOTHING to do with Java). JavaScript is a high level scripting language often used as a client side scripting tool and is standardized by the ECMA organization (ECMA-262 is the official standard)


General purpose markup language standardized by the W3C. So at its lowest level, AJAX is a JavaScript methodology for performing asynchronous client-side XML based HTTP requests behind the scenes.

Now, as we will see later, AJAX is based on XML. However, as with most of the latest JavaScript libraries out there, it is most commonly used without XML.

Basam pointed out to me the other day (from a book he was reading) that AJAX doesn’t even require JavaScript. To that author, I say pffffft! Scott Raymond, the author of AJAX on Rails, was referring to a Microsoft scripting language called VB script (those of you who are .NETers, I mean no offense by any of my following statements).

Microsoft’s Internet Explorer (IE) exclusive scripting language has the ability to perform Asynchronous calls since IE uses an ActiveX object to perform the request (unlike the standardized XMLHttpRequest object as we will see later). Instead of calling it AJAX, I would actually call it AVBAX (that is not the official name, just something I came up with because calling a VB script based “AJAX” is a contradiction to the name AJAX itself).

Rants about misnomers aside, we come back to what is at the heart of AJAX. A developer using AJAX (especially in a JavaScript library) should understand that AJAX is a non-blocking JavaScript call that uses standard HTTP protocol and must conform to the protocol.

With JavaScript, an HTTP request can be made using the standard HTTP methods (GET, POST, etc), modify request headers, read response headers, load the XML document returned, or simply read the response as text being returned. Two common practices with current JavaScript libraries is to return HTML or JavaScript instead of XML. XML can become taxing to parse in a client’s browser as it becomes larger and more complex, so returned HTML can be dumped into a DOM object and returned JavaScript can be executed. That’s about the highest level overview that can be given.

Next, I’ll talk about the heart of AJAX and explicit JavaScript details. I’ll try to keep it to where you can understand it even if you don’t know JavaScript, but unfortunately I will have to delve into some of the more gruesome details.

To start off, AJAX is rooted in the XMLHttpRequest object. Now, IE uses an ActiveX object called Microsoft.XMLHTTP (actually there is another one called “MSXML2.XMLHTTP.3.0”, but I don’t know what the difference is. You’ll have to refer to Microsoft for the answer). Now, aside from Microsoft again subverting the standards, they did manage to give their ActiveX object the same functionality as the standardized XMLHttpRequest object. This is the last point that I’ll make to specify differences between IE and everyone else.

The XMLHttpRequest object (hereafter referred to as “XHR”) has three aspects to look at: the request, the response, and all that lies in between. The request follows a distinct process: open the request, set the request headers (optional), and send the request and the related data (if any).

As a security measure, an AJAX request can only request a URL that resides on the same domain as the current page. Now, Microsoft allows Universal Browsing (of which Mozilla Firefox will not even allow), which permits cross domain AJAX calls. This is a severe security loophole in IE (one of the many). Other browsers may allow to Universal Browsing, but I have not extensively researched other browsers. Regardless, Universal Browsing is a security concern because it allows one site to get a handle of a session on another site and make malicious requests. The XMLHttpRequest itself does not protect against Universal Browsing, but browsers should handle this security issue, thereby allowing the developer to often times ignore this issue.

The XHR has an event listener (aka handler) that fires whenever the XHR readyState attribute changes (called onreadystatechange). The XHR readyState goes through 5 stages: unsent, opened, headers received, loading, and done. In the context of this discourse, we will only focus on the done state (you can find the definition of all of the states at These states are represented as integers 0 through 4. You assign a function to handle the readyState change, which can be a closure (remember this is JavaScript, so closures are a good concept to use). Now, at any time during the request, you can invoke the XHR abort method, which (for all practical purposes), aborts the request.

So, once you have reached the readyState of 4 (aka DONE), what do you do? Well, whatever you want. However, since XHR is an HTTP request, you must check the status. Fortunately, the XHR allows you to see the status, and even the status text of the HTTP response. This allows you to implement any error handling you want (and yes, JavaScript has try/catch blocks which are my favorite error handling control structure).

Once your XHR is DONE with at status of 200 (OK), then you are free to process the data. This is where freedom comes in. You can access an XML object (JavaScript is designed to crawl through a DOM and XML works beautifully here) and parse it, or you can access the textual representation of the response, which leads to the flexibility of being anything: XML, HTML, JavaScript code (using the eval method in JavaScript; this can be powerful.), JSON (again use the eval method), base 64 encoding of some document, an application specific serialized data structure, etc. This data is available in the XHR’s responseText attribute.

Hopefully this has helped you understand the technology that so many of our higher level frameworks sit on top of. Understanding the low level stuff makes a developer more productive and valuable. Often times we take these things for granted, but understanding how they work allows us to become better developers (especially when things go wrong). You can find a very detailed definition of the XMLHttpRequest object at Below is some code that implements AJAX so that you can see it in action.


// short hand the document.getElementById method
var $ = function(divId) { return document.getElementById(divId); };

//  AJAX will be a javascript object that has methods called update, evaluate, and sendRequest
var AJAX = {
    evaluate: function(url, method, data) {
        url: url,
        method: method,
        data: data,
        onreadystatechange: function(request) { if(request.readyState == 4 && request.status == 200) eval(request.responseText); }

    sendRequest: function(configs) {
      var self = this;

      // create the request object
      var request = (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject('MSXML2.XMLHTTP.3.0');

      // upcase the passed in method for continuity
      if(configs.method == null)
        method = 'POST';

      configs.method = configs.method.toUpperCase();

      // create the url encoded query string of the data object passed in
      var dataStr = "";
      for(i in
        dataStr += i + "=" +[i] + "&";

      // if not URL set, use the current one
      if(configs.url == null)
        configs.url = window.location.href;

      // if it is a get request, append the data string to the url
      if(configs.method == 'GET')
        configs.url += "?" + dataStr;

      // open the request, configs.url);

      // set the headers content type, if not explicitely set by the user
      if(configs.headers != null && configs.headers['Content-type'] == null && configs.headers['Content-Type'] == null && configs.headers['content-type'] == null)
        request.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');

      // set the request header, only required if POST method
      for(header in configs.headers)
        request.setRequestHeader(header, configs.headers[header]);

      // create the onreadystatechange event handler defined by the following closure
      // Note: closures are functions that have the scope of where they are defined
      //       hence, it has access to the request and divId objects
      request.onreadystatechange = function() { configs.onreadystatechange(request) };

      // send the request, if POST, send the request (POST) data
      if(configs.method == 'GET')

    //  update function will update the DOM object with id divId with the responseText returned
    update: function(divId, url, method, data) {
        url: url,
        method: method,
        data: data,
        onreadystatechange: function(request) {
        // are we in the done state with an HTTP status of 200 OK
        if(request.readyState == 4 && request.status == 200)
          $(divId).innerHTML += request.responseText;