Legitimate security concerns regarding cross-site HTTP requests are the reason why you can’t simply read in any old file. However, using appropriate page headers makes accessing files from other domains possible. So, if we can set page headers in a file that returns our data, it should be accessible, right? Right!

This can’t be done using a JSON file, but it can be done in a PHP file that is setup to output JSON. The PHP code would look something like this:

<?php
// Allow access from anywhere. Can be domains or * (any)
header('Access-Control-Allow-Origin: http://fiddle.jshell.net');

// Allow these methods of data retrieval
header('Access-Control-Allow-Methods: POST, GET, OPTIONS');

// Allow these header types
header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept');

// Create our data object in that crazy unique PHP way
$arr = array(array("id" => 1, "character" => "Minstrel", "line" => "And Saint Attila raised the hand grenade up on high, saying, 'O Lord, bless this thy hand grenade, that with it thou mayst blow thine enemies to tiny bits, in thy mercy.' And the Lord did grin."));

// Return as JSON
echo json_encode($arr);
?>

Note that you don’t have to use PHP. You can use just about any server side scripting language; ASP, .NET, ColdFusion, Ruby, etc., as long as you set the headers properly.

Check out an example:

[There is a JSFiddle embedded in this post. Please follow the link below or go to the site to see this JSFiddle.]

View this on JSFiddle

About a week ago while viewing my own post in Appliness digital magazine (shameless plug) I noticed that I couldn’t access the source code in the embedded iFrame. I wasn’t sure if this was an oddity with Appliness so I made a mental note to check it out.

The very next day I received a comment from a visitor stating that they were having the same problem when viewing the site on their phone. Obviously, I had a problem. I want my code to be viewable on as many devices as possible so I started looking into alternatives.

CodePen

For looks, you can’t beat CodePen. It’s definitely the Ferrari of the bunch. Its sleek black skin and optional upgrades made me want to take it for a spin. The CodePen window is made up of four frames, HTML, CSS, JS, and the Output. Each code frame has its own set of additional features/libraries accessible via a small gear icon in the upper right corner.

CodePen’s additional features are very slick and useful. The HTML frame allows you to utilize three useful templating tools, Haml, Markdown and Slim, at the click of a button. CSS provides easy access to Less and Sass as well as some other oft-used CSS functionality, like reset. And JS frame applies clickable access to Coffeescript and Modernize, as well as allowing you to add any external library of your choosing. It also provides a useful link to cdnjs.com where you can find a CDN reference to just about any library yo can think of.

CodePen felt great, looked great, and provided optional upgrades. Unfortunately, once you take it out of the garage and park it in your driveway, i.e., embed it on your site, it doesn’t necessarily run great.

As a matter of fact, my Angular code which works when viewed on CodePen, did not work at all on my site. The Ferrari of sandboxes actually seems more like a Fiero with a Ferrari kit.

JSFiddle

JSFiddle seems to be the most widely-used sandbox. It’s the most utilitarian of the three…the minivan, if you will. Its looks are very basic, and while it claims the ability to apply different skins when embedded, the only skins available are “light” (light gray and white) and “presentation” (light gray and white with a gigantic font). You would think if there was a “light” there would also be a “dark”, right? Nope. This minivan only comes in gray.

Like CodePen, JSFiddle displays HTML, JS, CSS, and output frames. It provides access to a slew of libraries via a too-huge dropdown list. It also provides a second dropdown with esoteric options like “no wrap – in head”, which actually turns out to be quite important. The rest of the options are hidden in a vertical accordion.

The most important difference between CodePen and JSFiddle, however, is only apparent when it’s embedded. JSFiddle works and CodePen doesn’t.

Plunker

Plunkr is a little different than the others. It’s no Ferrari, but it’s no minivan either. I guess it’s a Buick. It’s looks are more modern than JSFiddles, but its options are almost non-existent. The window only has two frames: code and output. You create your own files rather than using dedicated HTML, JS, and CSS frames. While this means that you can’t look at all of your code at once, it actually lends to its flexibility.

With Plunkr you can create multiple files in the same project. This means you can test more abstractly, and easily swap functionality in and out. Your HTML head is in your code window making it easy to see what’s getting loaded. Being able to create your own files also means being able to create external datasources, which is fantastic for playing with dataloading functionality.

The biggest problem with Plunker is the one I mentioned earlier. When it’s embedded, you can’t view the source files on mobile devices.

So, what do you drive, a Fiero/Ferrari, a minivan, or a Buick? Or something entirely different?

Check it out!

Learning Angular has been a fantastic experience so far. I’ve been consistently surprised at the results I can get from a screenful of code. This week’s Image Gallery experiment was no different. Before I get into the particulars, let’s take a look at the finished product:

If you check out the source app.js on that example you’ll notice that the JavaScript adds up to about 25 lines of code, half of which are dedicated to loading and setting the data source. Yes, there’s some CSS3 transition coolness thrown in, but even that is minimal.

So How Does It Work?

The gallery is made up of three sections: the main image, the caption, and the thumbnails. If you compare the main image section and the thumbnail section you’ll see that they’re very similar. The main difference being the size of the image how many of the image you can see:

<div class="mainimageshell">
    <div class="viewwindow">
        <ul id="fullscroller" class="fullsizelist" ng-style="listposition" >
            <li ng-repeat="image in galleryData">
                <img id="fullsize" class="large" ng-src="{{image.image}}" />
            </li>
        </ul>
    </div>
</div>

<div class="captionshell">
    <p class="caption">{{selected.desc}}</p>
</div>

<div class="thumbsshell">
    <div class="thumbswrapper">
        <ul>
            <li ng-repeat="image in galleryData">
                <div class="thumbwrapper">
                    <a ng-href="" ng-click="scrollTo(image,$index)">
                        <img class="thumbnail" ng-src="{{image.image}}" />
                    </a>
                </div>
            </li>
        </ul>
    </div>
</div>

If you were to comment out the overflow line of the viewwindow class you would see all of the images lined up side by side, just like the thumbnails.

When iterating over the data using ng-repeat, $index will reflect the zero-based index of each item. Since we’re looping over the same data, the index for both the large image and the thumbnail will be the same. This allows me to multiply the index by the width of the images to arrive at the new positioning for the large image list. Once I specify the new positioning, my CSS handles the transition, something like this:

ul.fullsizelist{
    position:absolute;
    top:0;
    left:0;
    transition:  left .8s ease;
}

Thanks to Angular, notifying the DOM element of its new position is ultra-simple. If you take a look at the fullscroller UL inside the template you’ll see that it contains the Angular ng-style directive and that it’s bound to the listposition property. Listposition is updated in the scrollTo function every time a thumbnail is clicked and any change is immediately reflected in the view:

// Scroll to appropriate position based on image index and width
$scope.scrollTo = function(image,ind) {
    $scope.listposition = {left:(IMAGE_WIDTH * ind * -1) + "px"};
    $scope.selected = image;
}

In addition to modifying the viewwindow position, the scrollTo function also assigns the currently selected item to $scope.selected. If you look at the template you’ll see that caption is rendering “{{selected.desc}}”. When $scope.selected is changed, the caption will automatically change with it.

Full Disclosure

My original idea was to fade out the old image and fade in the new image when a thumbnail was clicked. This worked great on Chrome, but Firefox would flash the image on screen once loaded and wouldn’t transition in properly. It also required transition end listeners, which at the moment are not standard across browsers. That meant separate listeners for each browser engine.

The whole thing was becoming a hassle and the code was getting unruly. That’s when I made the decision to switch to a slider and it worked out great. Point being, don’t be afraid to experiment or refactor. Oftentimes the best coding decisions are born out of a change in approach.

The Finished Product

JSON is a native object to AngularJS so working solely with JSON examples is easy. In the real world, however, you’ll probably need to deal with other types of data sources, like XML. Before I get too wordy, let’s start with what you’re really here for…the example:

The Explanation

While the finished product looks like the result of 15 minutes of coding, I have to admit that it took me significantly longer to figure out. If you search the Angular Developer Guide or API for “XML” you’re going to come up woefully absent of useful results. Googling won’t get you much further. As frustration began to set in, I started thinking about what made loading an XML file more difficult than loading a JSON file. The answer is: not much!

Bridging the Language Gap

Angular likes JSON, and can you blame it? Angular is a JavaScript toolset and JSON is JavaScript Object Notation, a native brethren. XML, on the other hand, is tag-based markup…a foreign language to Angular. What I needed was a way to make Angular understand what XML was trying to communicate.

The key to overcoming any language gap is to have a translator. If there were a way to translate XML to JSON before handing it to the application then I could eliminate the language gap, and the problem.

A quick search for xml converters turned up multiple results. I chose Abdulla Abdurakhmano’s X2JS library because it was the first one I came across, it was lightweight, and it was pretty easy to use.

The code required to perform the translation is short and simple. Provide the library with XML, tell it which method to use, and receive JSON in return:

function(xml) {
 var x2js = new X2JS();
 var json = x2js.xml_str2json( xml );
 return json;
}

Where to Stick It

Now that I had a solution to the language gap I needed to decide where to implement it. Angular’s $http service conveniently applies transformation functions for both requests and responses. These functions apply transformations to data when it is sent and received, and they can be overridden.

Using the X2JS conversion code as a transformResponse function it was simple to get the $http service to read in XML and return JSON to the application, effectively creating the translator I needed. The results look something like this:

angular.module('myApp.service',[]).
    factory('DataSource', ['$http',function($http){
       return {
           get: function(callback){
                $http.get(
                    'data.xml',
                    {transformResponse:function(data) {
                    	// convert the data to JSON and provide
                    	// it to the success function below
						var x2js = new X2JS();
						var json = x2js.xml_str2json( data );
						return json;
						}
					}
                ).
                success(function(data, status) {
					// send the converted data back
					// to the callback function
                    callback(data);
                })
           }
       }
    }]);
    
angular.module('myApp',['myApp.service']);

var AppController = function($scope,DataSource) {
    
    //This is the callback function
    setData = function(data) {
        $scope.dataSet = data;
    }
        
    DataSource.get(setData);
    
}

That’s really all there is to it! The example above will retrieve an xml file named “data.xml”, convert it to JSON, and assign the results to $scope.dataSet.

The Caveat

XML comes in all shapes and sizes. Some use attributes, others don’t, and many use a combination of both. Some XML files use a proper header, others are just fragments. Your application will likely require tweaking to get the data into the shape that your application requires. Always read the docs, read the comments, and experiment.

The example at the beginning of this post is a great starting point. Fork it and experiment with different libraries or XML formats.

Keep on Coding!

The Assignment

This week’s self-imposed Angular assignment was to create a small app that would dynamically filter a list of data using an input field as search criteria. I chose to base the app on my son’s homework assignment and use United States states and capitals.

In my previous examples I used Controllers for all functions and assignments. For simple non-critical applications the configuration works well, but for larger real-world applications a more abstract approach makes sense. Enter Angular Modules.

The Basics

Modules initialize Angular applications and wire together its services, filters, directives, etc. This makes the code portable, easier to debug, and easier to unit test.

To keep things simple, I only used a service in this example. The service is a gofer, responsible for carrying out any requests made by the controller. The controller sets scope properties and behaviors and handles calls from the template.

Here’s a basic module, service, and controller in Angular:

angular.module('myApp.service',[]);
angular.module('myApp',['myApp.service']);
var StatesController = function($scope) {}

On the first line is a service named ‘myApp.service’. Note that the dot is not necessary, nor is using the app name as a prefix. I could have named it ‘gofer’ if I wanted. The important part is that I let the main application module know the name, which brings me to line 2, the main module.

The main module names the app and gives it a a comma delimited reference to services, filters, etc. that can be referenced. If I defined a filter named ‘myApp.filter’ my module definition would have been: “angular.module(‘myApp’,['myApp.service','myApp.filter']);”. The module name, “myApp”, will be used in my ngApp directive in the template.

Line 3 is the shell of a controller definition which will be directly accessible by the template. While it wouldn’t do anything at this point, we could hook those three lines up to a template and assign myApp to the ngApp directive without error.

Let’s Get Some Data!

As with most applications, we’ll need access to data. My data source is a JSON file that looks like this:

[
    {"name":"Alabama", "capital":"Montgomery","abbreviation":"AL"},
    {"name":"Alaska", "capital":"Juneau","abbreviation":"AK"},
    {"name":"Arizona", "capital":"Phoenix","abbreviation":"AZ"},
    {"name":"Arkansas", "capital":"Little Rock","abbreviation":"AR"},
    ...
]

I need a way to create a resource object out of that data so I can interact with it. Angular’s ngResource module provides exactly what I need in its $resource service.

NOTE: The ngResource module is NOT in the base angular.js file. To use it you must load angular-resource.js in addition to angular.js. If you get an error in your debugging console that says “Uncaught Error: No module: ngResource”, chances are you forgot to load angular-resource.js. You do use a developer tools, right?

To retrieve the resource I utilized a method used to create objects in Angular called a factory. When I put the factory method inside my service, and then provide my Controller with a reference to it, I can use it in my controller to set a scoped property, like this:

angular.module('myApp.service',['ngResource']).
    factory('States', function($resource){
        return $resource('states.json', {},{
            get: {method: 'GET', isArray:true}
        });
    });

angular.module('myApp',['myApp.service']);

var StatesController = function($scope,States) {
    $scope.stateData = States.get();
};

So, what changed? First, I gave my service a reference to Angular’s ngResource module. That will give me the ability to use the $resource service for my factory allowing me to interact with my data source, “states.json”. Notice that the factory has a name, “States” which I provide to my Controller. From there I can access actions inside the factory, such as “get”, “save”, and “delete”.

Now, if I create a template referencing the controller I can display the data using my stateData property. Check out the source code here:

Make Something Angulary Happen

We now have a working module, a service, a factory, a controller, and data. Time to do something slick with it. Building off the html above, Inside my StatesController DIV I’m going to delete the current {{stateData}} dump and replace it with something a little easier to read:

<ul class="states">
   <li>
      <div class="resultwrapper">
         <span class="title">{{state.name}}</span><br>
         <span class="bold">Abbreviation:</span> {{state.abbreviation}}<br>
         <span class="bold">Capital:</span> {{state.capital}}
      </div>
   </li>
</ul>

Using ng-repeat and an unordered list, my state information now displays in a style-able list. Unfortunately, a couple of my states are not in alphabetical order. This can be fixed easily by telling the repeater to order it using a built-in filter module named orderBy after my iterator:

<ul class="states">
   <li ng-repeat="state in stateData | filter:criteria | orderBy:'name'">
       <div class="resultwrapper">
          <span class="title">{{state.name}}</span><br>
          <span class="bold">Abbreviation:</span> {{state.abbreviation}}<br>
          <span class="bold">Capital:</span> {{state.capital}}
       </div>
   </li>
</ul>

Note that ‘name’ is a string, not a reference. I could have also defined a property for it in the controller and used it with the orderBy.

Now that they’re in alphabetical order I want to be able to search them. This was done by adding a simple input and assigning it an ng-model of ‘critera’, then giving that to the ng-repeat filter. Angular uses the value entered into the criteria field as a filter for the stateData array. Throw in a style sheet and you have a pretty nifty widget using a very minimal amount of code.

The Result

This AngularJS example demonstrates how HTML5 and AngularJS can work together to provide a modern approach to form submission and validation without lengthy JavaScript validation algorithms, cumbersome CSS, or page refreshes.

Note that there are multiple ways to present and submit a form using HTML5 and AngularJS. Your implementation should depend on the needs of your application. The method I use here does not perform an actual submit. Instead, when the Submit button is clicked it calls a function that updates a visitorInfo object. Any action can be performed when the visitorInfo object is updated by modifying the update function in VisitorFormController in app.js.

The example provides immediate feedback based on the data entered into the input fields. Every input field has been flagged as “required” and you can watch the debugging info to see the status change dynamically as each input field is populated.

[There is a JSFiddle embedded in this post. Please follow the link below or go to the site to see this JSFiddle.]

View this on JSFiddle

Let’s take a closer look at the email section to see how this is done:

<span class="label">Email:</span>
<input type="email" name="email" placeholder="Email" required="" />
<span class="valid">?</span>

The first line is simply the label that is show before the input field. The “label” class lets me apply some styling to keep it on the same line as the input field, make it bold, etc. No magic there.

The input field has several attributes. Name gives us a means of referring to that specific field. Type defaults to “text” but we’ve given it the HTML5 type of “email”. Doing so implements validation rules, such as requiring an & and a domain type (like .COM). It also causes responsive mobile devices to present different UI. For example, assigning a type of email will cause “.COM” to appear on keyboards of many mobile devices.

The ngModel directive links the input field to a scope property, in this case visitorInfo.email. visitorInfo is an object that holds all of the form properties. Notice that each input field model includes visitorInfo before the property name. You can watch visitorInfo populate in the debugging info as you fill in the form.

Placeholder is a new input attribute that allows you to define a short data entry hint that will appear inside the input field. The hint disappears when the user starts entering text but will reappear if the text is deleted. Placeholder text does not get submitted as form data.

Finally, there is the required attribute that defines the field as one that must be filled in for the form to be considered valid.

The span below the input field contains a checkmark that is not visible when the page first loads. The AngularJS ngShow directive has an evaluation in it that will only allow the span to be visible when the field passes email field passes validation rules.

Negative feedback is provided courtesy of CSS and AngularJS. Enter a value in the First Name field and then delete it. The field background will change to red. If you look in style.css you’ll see the following section:

input.ng-invalid.ng-dirty {
	background-color:red;
}

ng-invalid and ng-dirty automatically get assigned as classes based on the input field state. If the field contents are invalid then the input field will be dynamically assigned the ng-invalid class. We can use that class to style the field in certain circumstances as I did above. Pretty slick! See the AngularJS API for more information on these class assignments.

Finally, check out the Submit and Restore buttons. The Submit button’s job is to update the visitorInfo object. The restore button restores all of the field data to the last submitted value.

Both buttons react to the state of the form. The submit button will enable and turn green when the entire form has been filled out with valid information. The restore button enables when the form data differs from the stored visitorInfo object data.

This functionality is done using a combination of AngularJS’s ngClick and ngDisabled directives:

<button ng-click="reset()" ng-disabled="isUnchanged(visitorInfo)">RESTORE</button>
<button class="submitbtn" ng-click="update(visitorInfo)" ng-disabled="valForm.$invalid || isUnchanged(visitorInfo)">SUBMIT</button>

ngDisabled contains an evaluation. If the evaluation is true then ngDisabled will also be set to true, making the buttons un-clickable. If they evaluate to false then the buttons will become enabled. Once they are enable, they can be clicked and the clicks will be handled by the functions that are referenced in the ngClick directives.

All in all it was very easy. The code itself is MUCH shorter than this post, which is a testament to the simplicity of AngularJS and HTML5 (or it could be just an indication that I’m too wordy.) In either case, I’m using that line as an opportunity to wrap this post up.

As always, check out the code on Plunkr. Fork it, edit it, experiment with it. It’s the best way to learn.

My goal for this AngularJS experiment was to create a multi-level menu with a hide-away submenu, fed from an external data source. The sub-menu should appear when its parent is clicked. As with my other AngularJS examples, this turned out to be a very simple task involving minimal code.

[There is a JSFiddle embedded in this post. Please follow the link below or go to the site to see this JSFiddle.]

View this on JSFiddle

One directive in the example that I hadn’t used before was ngStyle which facilitates dynamic style assignment. I use it here to position the submenu under the appropriate parent item. The directive is assigned to the ul block, and when the parent item is clicked, a function is called that modifies the scoped ‘subLeft’ property, something like this:

<ul>
   <li ng-click="setStyle()">menu item</li>
</ul>
<ul ng-style="subLeft">
   <li>submenu item</li>
</ul>

$scope.setStyle = function() {
   $scope.subLeft = {'padding-left':'80px'};
}

One hurdle I had to overcome was that ng-click only takes an Angular expression, which does not use JavaScript eval() to evaluate. I wanted to send the id of the element that was clicked so I could derive its coordinates as a way of knowing where to place the submenu. Without the use of JavaScript I was unable to do that.

In the interest of keeping the example simple, I ended up sending the Angular iterator index instead of the element id. Since all of my menu items are the same width it was a matter of multiplying the index by that width to arrive at the correct positioning. Problem solved!

“XSL stands for EXtensible Stylesheet Language, and is a style sheet language for XML documents. XSLT stands for XSL Transformations.”

Overall the experience was a good one. It was very easy to figure out how to display an XML document in an HTML report format. It was also very easy to style the report using attribute sets. Essentially, attribute sets allow you to define styles for different elements in your document. Elements use “use-attribute-sets” to define the sets that should be applied. For example:

<xsl:attribute-set name="bodystyle">
    <xsl:attribute name="bgcolor">
        #cccccc
    </xsl:attribute>
</xsl:attribute-set>

<xsl:template match="report">
    <html>
        <body xsl:use-attribute-sets="bodystyle">
            <xsl:apply-templates select="headerData"/>
            <xsl:apply-templates select="reportData"/>
        </body>
    </html>
</xsl:template>

The code above would make the body background color #cccccc. Works great. But what if I wanted to set a property that isn’t an attribute of the element. What if I want to set the font color, for example. There is no “color” attribute for body. In this case, the style attribute can be used:

<xsl:attribute-set name="defaultfontcolor">
    <xsl:attribute name="style">
        color:#111;
    </xsl:attribute>
</xsl:attribute-set>

<xsl:template match="report">
    <html>
        <body xsl:use-attribute-sets="defaultfontcolor">
            <xsl:apply-templates select="headerData"/>
            <xsl:apply-templates select="reportData"/>
        </body>
    </html>
</xsl:template>

So far, so good. The cool thing about attribute sets is that they can be combined, too. Let’s say I want to combine the two examples above and set the body color and font color at the same time. I could define both in the same attribute set, but I want to use the font color elsewhere without the bgcolor. This can be done easily:

<xsl:attribute-set name="bodystyle">
    <xsl:attribute name="bgcolor">
        #cccccc
    </xsl:attribute>
</xsl:attribute-set>

<xsl:attribute-set name="defaultfontcolor">
    <xsl:attribute name="style">
        color:#111;
    </xsl:attribute>
</xsl:attribute-set>

<xsl:template match="report">
    <html>
        <body xsl:use-attribute-sets="bodystyle defaultfontcolor">
            <xsl:apply-templates select="headerData"/>
            <xsl:apply-templates select="reportData"/>
        </body>
    </html>
</xsl:template>

As you can see in the body tag I’ve listed both attribute sets, separated by a space. This works great!

Now here’s the gotcha. The last attribute set in the list will override previous style definitions of the same attribute. Normally, this isn’t a problem…as long as you’re not using the style attribute in more than one set. While the style attribute can define more than one element property, “style” itself is the attribute. Therefore, if you try to combine two attribute sets that both define “style”, only the last one will be implemented, regardless of whether they define different properties.

For example, although the code below defines the same styles as the one above, only the defaultfontcolor attribute set will be implemented. This is because both sets define the same attribute: “style”.

<xsl:attribute-set name="bodystyle">
    <xsl:attribute name="style">
        background: #ccc;
    </xsl:attribute>
</xsl:attribute-set>

<xsl:attribute-set name="defaultfontcolor">
    <xsl:attribute name="style">
        color:#111;
    </xsl:attribute>
</xsl:attribute-set>

<xsl:template match="report">
    <html>
        <body xsl:use-attribute-sets="bodystyle defaultfontcolor">
            <xsl:apply-templates select="headerData"/>
            <xsl:apply-templates select="reportData"/>
        </body>
    </html>
</xsl:template>

It doesn’t matter that one defines background and the other defines color. It only matters that they both set the “style” attribute. And because defaultfontcolor is last in the use-attribute-sets list, its definition is used over bodystyle.

My goal with today’s AngularJS experiment is to load data from a JSON file, iterate through all the data, and dynamically display detail data from a clicked list item. This proved to be incredibly simple and ended up taking less than 50 lines of code, including comments!

The data loading is done using the AngularJS $http service. In this example, the data object is assigned to $scope.artists when it has been successfully loaded:

$http.get('artists.json').success(function(data) {
   $scope.artists = data;
});

Once the data is loaded I can iterate over it using the AngularJS ng-click directive. The code below loops over each record in the artists object that I loaded above. It displays the artistName property found in each artist and then assigned a function (setSelectedArtist) that will be executed when the name is clicked.

<ul>
	<li ng-repeat="artist in artists">
    	<a href ng-click='setSelectedArtist(artist)'>{{artist.artistName}}</a></li>
	</li>
</ul>

When an artist name is clicked, its artist object is passed to the setSelectedArtist function found in ArtistsController. setSelectedArtist assigns the artist to the scoped selectedArtist property. When that occurs, page references to selectedArtist are updated to reflect the new assignment:

<div class="detailimagewrapper">
    <img class="detailimage" src="{{selectedArtist.img}}" >
</div>
<p>{{selectedArtist.description}}</p>

Check out the example on Plunker. It’s well-commented and easy to modify. Try adding the artist’s genre to the detail section. Or add a new field, like recordLabel or dateFormed.

This post is barely the tip of the iceberg regarding what the AngularJS $http service offers. Check out the documentation to learn more.

This is the third in a series of posts detailing my experience learning AngularJS. This post and its accompanying example discusses the handling of scope. AngularJS scopes go hand and hand with the DOM (Document Object Model). DOM objects within a controller reference rely first on their controller counterparts for their property assignments.

The example below includes three controllers: Limericks, Limerick1 and Limerick2. Limerick1 and Limerick2 use identical property names, but each are given unique values. If you look at index.html you’ll see two DIVs with ng-controller references to their respective controller definitions in app.js. Because they’re separate DOM objects, they can use the same property names locally.

Try changing the “Title” and “Field” values within each of the limericks. Notice that only one limerick changes even though its property names are identical to the other limerick. (Sidenote: the example scrolls down quite a bit. To view it on a full page, open it up in plunker and click the eye icon on the right to view the rendered page)

[There is a JSFiddle embedded in this post. Please follow the link below or go to the site to see this JSFiddle.]

View this on JSFiddle

AngularJS controllers aren’t limited to local property definitions, though. They also inherit from parent scopes. Look at the DIV that references the Limericks controller. Notice that it wraps around both Limerick1 and Limerick2. This allows Limerick1/2 to inherit from Limericks.

To illustrate inheritance, {{author}} is defined only in Limericks but it’s used within all three controller objects. Try changing the value in the “Global Author” field to see how it changes in all three scopes.

But wait, there’s more! Inherited properties can be modified locally without affecting the parent value. Like {{authors}}, {{pageTitle}} is also only defined in the Limericks controller. Its value is “Pretty Bad Limericks”. The first instance of it on the page is outside of Limerick1 and Limerick2. The second instance is within Limerick1 and the third is within Limerick2.

Try changing the first instance by modifying the value in the “Parent pageTitle” field. Notice that both pageTitles change. Now try changing the value in the “Inherited pageTitle” field. Only the local value changes. Limericks1 {{pageTitle}} is now uncoupled from its parent value since it has been assigned a local one. If you change the first instance again you’ll notice that the Limerick2 instance is still inheriting but Limerick1 is not.

For more information on AngularJS scopes, see the dev documentation.