In my recent post I presented few form templates which was full of duplicate codes. In this post, I will show you how to harness the power of AngularJS Directives to create small reusable code snippets that share common behaviors and avoid duplication. AngularJS Directives probably the most complicated thing in the whole angular framework, there are quite a few things that you need to understand like compiling, linking, nested scoping, transclusion etc.. in order to master it. But in the case, we are going to create few basic directives which does not require an angular expert to understand it. But before it, lets see the original version of the markup where it was full of duplication:

In the last post, we have completed the category management, in this post I will show you how account list is implemented. The account management will be typical CRUD screens, where the accounts will be shown in a html table and each row will have links to edit and delete individual account, there will be separate screens to edit and create account. Lets list the features in a bit more details:

Lately I started to dig around AngularJS framework, one of the thing that I often found helpful is to port an existing codebase to the new thing that I am trying to learn, so I decided to create an AngularJS version of my Backbone.js StarterKit.  I have been working with Backbone/Spine for more than a year and I am well familiar with the basic building blocks of these client side mv-* frameworks, but there are certain features of AngularJS that I really like, to name few the composition over inheritance (no need to inherit from special framework class), dependency injection and testability. The other important feature is creating extension of html vocabulary known as directive, I am still investigating the Angular source to fully understand it, so it is too early for me to comment on this, but having worked with many years in asp.net webforms which as well abstracts the html generation, I can say there are obviously some concerns. Nevertheless, AngularJS is a powerful framework  for building rich client side applications and does worth looking into it.

In the previous post, we have seen the UIs and its functionalities, in this post we will see how the category list is implemented. Typically CRUD UIs are presented in html tables to list the records and separate screens for adding and editing individual record, but in this case the category has only two attributes the title and the type(expense or income) so instead of creating multiple screens we will be using the same list view to add, edit and delete the categories. Lets recap the functionalities of category list:

This is a first part of a multi-part series article where I will show you how to create a relatively simple CRUD Application with Backbone.js. The Application is a personal finance application where the user will be able to create multi-currency accounts and should be able to track expenses and incomes. The application is created with the Backbone.js Starter Kit of my previous post and the full source code is hosted on GitHub.

Recently I completed few Backbone.js Single Page Applications, one of the thing that really bored me was setting up the project. It seemed that I was doing the same stuff over and over again like setting up the folder structures, installing the required nuget packages, writing the same user registration and login codes etc. So I decided to create a project template which I can use as a starting point for my application and thus born the Backbone.js StarterKit and thankfully and it is now showcased in asp.net single page application section. It was initially created as a VSIX extension, I know unlike myself, people often do not like to install something new unless it is absolutely necessary, so I have also created separate nuget packages that includes all the features of the VSIX template, just create an empty ASP.NET MVC project and install your preferred package.  Although my preferred client side language is CoffeeScript but I encounter clients who prefers pure JavaScript as well as clients who become fan of typescript due to its auto complete and compilation support in VS.  So there are three separate nuget packages which are same but implemented in different languages. To Install the package, open the package console in VS and type your preferred version:

In the last post, we have used Html5 local storage for persistence, in this post we are going to integrate it with ASP.NET MVC. Before moving forward, let me tell you that frameworks like backbone.js and spine.js expects your server endpoints are RESTful and do utilize the http verbs, for example the same endpoint can perform different things based upon the http verb. Unlike Rails, the default Controller and routes that ASP.NET MVC generates does not have those features. So we need to tweak the ASP.NET MVC to improve its “RESTful-ness”. In case, if you are wondering about the url structures, here is the list of defaults of ASP.NET MVC:

Take a cup of coffee or light up your smoke, this is going to be a lengthy post, I know this is long due to some of my friends over twitter and reading after Rob Conery’s “The BackboneJS and Knockout DanceOff” I decided to start writing it finally. This post will cover a basic introduction of Spine.js, the things you have to do to integrate it with ASP.NET MVC and finally why Spine.js is my framework of choice when there are other popular alternatives for the client side development.

I will be writing all of my client side codes in CoffeeScript, if you are new to CoffeeScript then do visit CoffeeScript official site (the previous link) and there are also few more free resource like little book of CoffeeScript, Smooth CoffeeScript or blog post series of Jan Van Ryswyck which you can check. In order to compile your CoffeeScript to JavaScript inside Visual Studio you can use the new tool Web Workbench from the good guys of Mindscape or the popular open source add-in Chirpy. You can of course use the plain old JavaScript but after writing CoffeeScripts in last four months I can only say I am not going back to the plain JavaScript unless the languages features that exists in CoffeeScript are introduced in JavaScript. In short, CoffeeScript is a tiny little language which brings most of the good stuffs from Ruby, Python and probably from Perl to write highly readable and beautiful codes that compiles down to JavaScript.

As you know that I am a big fan of Ruby Sinatra and I was really amazed to learn that Sammy.js does exactly the same but in the client side. In this post, I will show you a fully functional application developed in Sammy.js. Before moving forward, let me tell you that Sammy.js is best suited for creating single page application like GMail, Pageflakes or any kind of Dashboard type application where SEO is not a concern . But for this post I will show you the Bakery sample in Sammy.js that I have previously converted to Sinatra from Microsoft WebPages (aka WebMatrix) and it is not an ideal candidate for Sammy.js but it covers the basics to get you started. I am also using ASP.NET MVC in the server side and JavaScript version of Mustache in the client side(though it is not as much as popular in .NET Community comparing to others) but you can use any other server side technology as well as different template engines including the jQuery template which Microsoft contributed to jQuery. You can see the Sammy Bakery live in action by clicking this link here, you can also download the complete source at the bottom of this post.

Lately, I have been playing with few JavaScript frameworks and in today’s modern web applications it is very common that we are including tons of JavaScript files in our application. One of the thing that plays important role in application performance is how fast these script files are delivered into the browsers. I have extensively blogged on combining, compression and caching of JavaScript files in my old blog, in this post I will show you, how you can achieve parallelism in delivering the scripts in the browser with the Head JS library. If you do not know what parallel script downloading is and how does it impact on page speed, then I would suggest to read this article of the YSlow creator. In short, when a browser encounters a script tag in a page it halts its rending until it downloads the script file, the parallelism is actually archived by adding the script dynamically or by XHR depending upon the browser it is running.