Am I Doing Dynamic Views with AngularJS Right?

I have played around with a lot more JavaScript and single page applications (SPAs) as of late. More specifically, I have fiddled with AngularJS in my most recent personal project and it has been a lot of fun. However, client side web application development is not the same as server-side web application development. In this post, I will describe a challenge I had with client side routing using AngualrJS, how I solved it, and how I feel about the solution. Hopefully, somebody will give me a little feedback on my approach.

The Problem

The Facebook home page when you are not logged in.

The Facebook home page when you are not logged in.

At the root level of my web site, I want to show one view to an authenticated use and a different view to an anonymous user. This is a very common need and feature in many web applications. For example, let’s look at Facebook. When you point your browser to http://facebook.com, you will get one of two things depending on whether you have an authenticated session. If there is no active session, then you are presented with a welcome message which asks you to create an account. If there is an active session, then your get your timeline.

The solution for this from the server-side is actually simple. When the server receives the request for the home page, then we can simply check the session and use it to decide which view to respond with. Done. Easy as pie!

With a SPA, the solution wasn’t as clear. At least not to me with my limited AngularJS experience.

Solution

To be honest, I hope somebody else has a better solution than this to share with me. But this is what I did. I started an app.js file containing some simple AngularJS configuration logic:

The template pulled down by the root route was empty at this point and I was forced to make a choice. Should this template contain the welcome page content? Or should it contain the authenticated user content? Or what?

I decided it would contain the authenticated user content. This is because I expect (well more like hope) that most people who visit my application will log in and use it. This hopeful assumption made sense and so I set out to build my home page controller.

The first thing that I thought I would do was to inject the $http service so I could make a call to my website’s API and get the user’s session object. If I get a session back then I can go ahead with displaying the home page for the authenticated user. If I don’t then I can route them to the welcome page using the injected $location service and ask them to sign up or log in.

At this point my update app.js file looks like this:

Thoughts

This approach is very simple. At the end of the day, it is not really what I wanted. What I wanted to do is to dynamically tell the $routeProvider which tempalteUrl to use dynamically. This is probably due to my experience writing server-side MVC logic to select a view based on the session state. I didn’t like that I now have an extra route for my welcome page. This doesn’t feel right to me. At least, it doesn’t feel natural.

Another approach that I considered after this implementation is using an ngView directive in my template and dynamically setting the templateUrl value using the $scope in the controller. However, I don’t like the idea of branching logic in the controller to populate the scope differently based on the session. That doesn’t feel right either.

So what’s next? Well, I think I am going to stick with this solution for a bit and probably create a session service to get the session object since I will probably need it between various controllers. I will probably also push a response interceptor in the $httpProvider to handle unauthorized responses from the API. While I am not entirely comfortable with this approach yet. It looks promising giving my limited exposure to AngularJS. I am hopeful that a fellow reader may offer some suggestions and/or advice.

Fork me on GitHub

RavenDB Quick Start Screencast

I have created my first screencast ever! I am probably just being way to critical, but having watched it I noticed a ton of things that I could have done better. I learned a lot and it was fun! So I will probably do more of these in the near future.

At any rate, here is the video. I hope you enjoy it.

Before I forget, I should mention that will be presenting a session on RavenDB at the following venues:

Intro to RavenDB at Austin Code Camp 2012

If you would like to see the source code for the Depot Application in MVC 3 with RavenDB presented towards the end of the presentation, it is available on GitHub.

Don’t forget to check out the upcoming Central Texas GiveCamp! I am really looking forward to seeing the developer community get together to give to charity.

RavenDB Document Identifiers and MVC Routes

Following my recent post about getting started with RavenDB, I decided to work on a small shopping cart demo application based on the sample depot application that is written in part 2 of Agile Web Development with Rails when I started running into some trouble with the RavenDB auto generated document identifiers and the MVC routes. Like any other programmer, I quickly performed a Google search to see what others had done. The search led me to a few Stack Overflow well voted answers all leading me to a blog post on this topic. Problem solved right? Not exactly. Two solutions were proposed. But before getting into those, I want to describe the problem a little more.

The Problem Described

Take a look at the ASP.NET MVC 3 default route found in the Global.asax.cs file:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

This default route will basically allow you access to a resource using the basic URL convention that may look something this: http://localhost/products/edit/1 . However, the default RavenDB auto generated document identifier for the product document ends up looking something like this: products/1. (More information about the RavenDB document identifiers one of the documentation pages. ) So the URL to access that product resource for editing would really have to look like this: http://localhost/products/edit/products/1. Well that doesn’t work for two reasons:

  1. The default route will not be matched so the URL will not be routed the correct controller action.
  2. The URL is not SEO friendly.

Typically, this can be solved by using a custom route that access this resource by a natural key where the URL would probably end up looking like this: http://localhost/products/product-name/edit. This makes the URL SEO friendly, easy to read, and easy to route. However, there are some situations where the document identifier makes sense and I will continue this post on the assumption that this is the case.

The blog post mentioned above presents two solutions:

  • Solution 1 – Change the identity parts separator convention for the RavenDB document store.
  • Solution 2 – Modify the ASP.NET default route

Issues with Solution 1

Let’s look at the first solution. The suggestion is to change the identity separator convention from a slash (/) to a dash (-). The convention is really easy to change during the initialization of the document store object.

This makes RavenDB generate document identifiers that now look like: products-1. Now we can generate a URL that will match the default route and may look like: http://localhost/products/edit/products-1. I still find some issues this this. Namely, the URL is still not really SEO friendly and not really human readable. I don’t like the idea of exposing an identifier that was forced on me by RavenDB since it essentially has coupled my URL to the RavenDB identifier convention. It just doesn’t feel right.

Issues with Solution 2

This solution suggests the change of the default route to something like:

This will allow route to match a URL that looked like the first one: http://localhost/products/edit/products/1. I don’t like this either. While it does allow the default route to match and do its job. The URL is just ugly. It also clobbers the id making the route also match something like this: http://localhost/products/edit/products/more-junk/1. Obviously this is not SEO friendly or human readable. Again, it just doesn’t feel right.

Another Option

After some digging and learning about more about the document identity field, identity type converters, custom identifiers with the document key generator convention, I realized there was a pretty simple alternative to the two options above. But to see it and to understand the simplicity, you have to look at the source of the problem.

The reason that MVC routes are choking on the preconfigured RavenDB document identity convention is because our models included a string based identity property. I realized I had done this on purpose to ease the mapping of the RavenDB document identifier and my object identifier. Take a look at my product object definition:

The shopping cart identifier is a string. Why would it be a string? It could have been an integer or a Guid or something else. It could have even been a natural key of some sort. Or even a compound key. It doesn’t have to be a string. Taking another look at the  IDocumentSession interface we can see we have four load methods available.

After thinking about the difference between the method that accepts a string identifier and the one that accepts a value type identifier, I realized that all I had to do was change my identifier type from a string to a value type and I’m done. No fancy mapping or parsing the document identifier from RavenDB to the web browser and back. No changes to the default MVC route. No changes to the default identity separator convention. It just worked. My URLs are SEO friendly and more readable.

All I had to do was change the object identifier type.

That was easy.

Of course this doesn’t solve everything. What if I really do need a string based identifier? This will probably require tweaking the behavior of the RavenDB client. I also don’t have an answer for compound keys and other natural keys which may not be a value type. Some of these may require more thought from both the RavenDB side and the MVC side of my project. But that is another problem to think about some other time.

TODO: When Creating a New ASP.NET MVC Project

Michael Kennedy put this great little blog post together outlining 9 things we can do when starting a new ASP.NET MVC 3 project. It’s a good starting point since the MVC 3 web application template is already out of date with many things. Here is a quick run down of the things I do and don’t in comparison to his list:

  1. Remove the MicrosoftMvc*.js AJAX and validation scripts.
  2. Update NuGet packages… I do things a little differently here. I completely remove the EntityFramework package (I may add it or another ORM back in later, but that ends up usually in a persistence specific project and it is usually a micro ORM). I also remove jQuery Visual Studio 2010 Intellisense package since the contents are bundled with the updated the other jQuery packages anyway. I remove the jQuery UI package (and add it back when I need it). Update the remaining jQuery and Modernizr packages.
  3. Create my own JavaScripts directory to avoid overwrites when updating or installing other JavaScript based packages.
  4. Love this tip! Who doesn’t like intellisense?
  5. Already did this in step 2.
  6. I’m not the sharpest tool in the shed when it comes to CSS. But this tip sounds like a good idea. Wonder if there is a NuGet package for Eric Meyer’s reset.css file?
  7. I skip this step. In my opinion, the only models in my MVC project are view models anyway. So I leave the Models folder in my MVC project alone. If my project requires business models, they get placed in a business logic project. If I have persistence models, they get placed in my persistence project.
  8. Another area where I am not the sharpest tool in the shed. But I do like fast loading pages, so I am going to try this tip out and put all the JavaScript files that I can at the bottom. Just remember that some do need to go at the top.
  9. And yet another tip that I haven’t tried, but plan.

As a recap, tips 1, 3, and 4 make perfect sense. Tip 2 also makes sense, but I tweak it to fit my needs and I suggest you do to. I glaze over tip 5 and skip tip 7 because it was either previously addressed or doesn’t fit my needs. Tips 6, 8, and 9 sound like good ideas and I need to try them out.