Bootstrap Modal with AngularJS

We’ll look at a relatively low hanging fruit in case you’re working with vanilla AngularJS and Twitter Bootstrap and are not relying on other add-ons such as AngularUI’s Bootstrap extension. One common need I have is to be able to show or hide Bootstrap modals based on a property on my view-model. Here’s a simplified view of the controller:

var app = angular.module('app', ...);

app.controller('ctrl', function ($scope, ...) {
    $scope.showModal = false;

And here is the HTML:

<a href="#myModal" data-toggle="modal">Show Modal</a>
<div id="myModal" data-backdrop="static">
        Modal text goes here.
        <button data-dismiss="modal">Close</button>

In order to maintain separation of concerns, I want to be able to show or hide the modal as the value of showModal changes. This is another good use for directives in AngularJS. As with the datepicker example, we need a directive that will add a watch on link and use the JavaScript methods available with Bootstrap to control the modal, rather than the data-toggle or data-dismiss attributes.

The directive would then look like:

app.directive('akModal', function() {
    return {
        restrict: 'A',
        link: function(scope, element, attrs) {
            scope.$watch(attrs.akModal, function(value) {
                if (value) element.modal('show');
                else element.modal('hide');

Here, we are calling the Boostrap method modal on the element to which the directive is applied, i.e. the div that is the modal container. The HTML modified to work with this directive then looks like:

<a href="#" ng-click="showModal = true">Show Modal</a>
<div ak-modal="showModal" data-backdrop="static">
        Modal text goes here.
        <button ng-click="showModal = false">Close</button>

The modal display is now bound to showModal. Note how we got rid of data-toggle (along with the id on the div) and data-dismiss. Now, if some property on the view-model needs to control whether the modal is displayed, then it would not make sense to have a link hardwired to trigger the specific modal anyway. The case for data-dismiss is different though.

Another thing to consider is – if you have a lot of modals and a lot of different view-model properties controlling them, you are going to have a lot of watches, which you probably don’t want. If we make the assumption that mostly you’re going to have one modal visible at a time (unless you have multiple levels of modals going on – in which case personally I think you would need to rethink the UX you are providing), you can make something more generic such as a modalService that will work with a single modal div and have a showModal operation that takes the content to display in the modal. There would need to be a corresponding hideModal operation as well, of course. I plan to explore this further.

Now, back to the data-dismiss thing. What we have at the moment is somewhat of a one-way binding. It would be ideal if this could be made two-way so that closing the modal using data-dismiss automatically set showModal to false. At the moment, I have not given this enough effort to be able to do it in an acceptably performant way. If someone has, I would love to hear about it.

Writing your own LINQ provider, part 4

This is the last in a short series of posts on writing your own LINQ provider. A quick outline of the series:

  1. A primer
  2. Provider basics
  3. A simple, pointless solution
  4. A tiny ORM of our own (this post)

A tiny ORM of our own

In the previous post, we took a look at a simple, albeit pointless example of a LINQ provider. We wrap the series up this time by looking at something a little less pointless – a LINQ-based ORM, albeit a very rudimentary one. As with the previous one, it helps to take a look at the source code first:

This is a very simple example implementation and has its limitations. It only works with SQL Server. It only supports reads. It only supports these methods:

  • Any
  • Count
  • First
  • FirstOrDefault
  • Select
  • Single
  • SingleOrDefault
  • Where
  • OrderBy
  • OrderByDescending
  • ThenBy
  • ThenByDescending

There are a few more limitations, but again the point is not to redo NHibernate or Entity Framework. There is also a simple fluent mapping interface that you can use as so:

    .Member(x => x.Id, "id")
    .Member(x => x.Name "thing_name")
    .Member(x => x.Date "thing_date");

Once you’ve got your mappings in place, it is up to you to create the DB connection. Once you’ve done that, you can create an IQueryable<T> out of aSqlConnection instance and then do LINQ on top of it.

using (var conn = new SqlConnection("..."))
    conn.Profile(Console.WriteLine); // Write generated query to console.

    var query = conn.Query<MyThing>();

    var things = query
        .Where(x => x.Id < 1000)
        .OrderBy(x => x.Name)
        .Select(x => new {x.Id, x.Name, x.Date})

Or, using the “other” syntax:

var things = (from item in query
                where item.Id < 1000
                orderby item.Name
                select new { item.Id, item.Name, item.Date }).ToArray();

If you recall Step 2 from provider basics, there were two options. The last solution used Option 1, i.e. there is one queryable that just builds up the expression and the enumerator does the parsing. For this one, we’re using Option 2, where we have a separate implementation of IQueryable<T> for each type of query operation to support.

When you first obtain a queryable, you get an instance of TableQueryable (which is descended from SqlQueryable) corresponding to the table that the type is mapped to. Each call on top of it then wraps the queryable in another descedant of SqlQueryable (e.g. WhereQueryable for Where operations, and so on). This logic is in SqlQueryProvider. Similarly, for executable methods, the appropriate type of ExecutableBase is created and called. Beyond this, the actual query creation logic is implemented in the individual queryables and executables defined within the Constructs namespace.

The queryables and executables work with classes within the QueryModel namespace that represent parts of a SQL query. Based on what operation they stand for, they convert an Expression into a Query, which can then be converted into a SQL string. Each queryable implements a Parse method that does this, and as part of doing this, it parses the queryable it wraps and then works on top of the Query object returned by the inner Parse, and so on until the top-most enumerable gives you the final query. The innermost or leaf queryable is always TableQueryable which simply adds the name of the source table to the query model.

LINQ is undoubtedly awesome, but knowing how it works gives you new appreciation for just how powerful it can be. Man, I love LINQ.

Writing your own LINQ provider, part 3

This is the third in a short series of posts on writing your own LINQ provider. A quick outline of the series:

  1. A primer
  2. Provider basics
  3. A simple, pointless solution (this post)
  4. A tiny ORM of our own

A simple, pointless solution

In the previous post, we took a look at what happens when you call LINQ methods on IQueryable<T>, and how you can use that to build your own provider. We take that a step further this time by building an actual provider – albeit a somewhat pointless one, in that it adds LINQ support to something that doesn’t really need it. The point, though, is to keep it simple and try to understand how the process works.

The best way to understand is to take a look at the source code first:

Now, a quick summary of what this is.

We have an interface, INextProvider. It has one method, GetNext that is supposed to get the next one in a sequence of items. An example implementation that uses a simple array as the underlying store is also included. Once you have an instance of INextProvider<T>, say, callednextProvider, you can then extract an IQueryable<T> out of it with this call:

var query = nextProvider.AsQueryable();

You can then use standard LINQ on top of it. Now, I know what you’re thinking: this INextProvider seems uncomfortably similar to IEnumerator – why would we need a query provider for this? We don’t, hence the “pointless” part, but again – the idea is to examine how building a provider works.

The entry point is NextProviderQueryable which implements IQueryable<T> and uses NextProviderQueryProvider as its Provider and returns aNextProviderEnumerator from its GetEnumerator() call. This means that whenever one of the LINQ methods are called on an instance ofNextProviderQueryable, one of the following happens:

  • If the method is something that creates another queryable out of the existing one (e.g. WhereSelectSelectManyCast, etc.),NextProviderQueryProvider.CreateQuery() is called. That, in turn, creates a new instance of NextProviderQueryable, but with the Expression set to what has been passed in. Thus, every call to CreateQuery ends up creating a new queryable with the Expression property representing the complete call.
  • If the method is something that enumerates a queryable (e.g. ToListToArray, etc. or a foreach loop), the GetEnumerator() method is called and enumeration starts. This means that NextProviderEnumerator takes place. This object is initialized with the current value of Expression as of the time of enumeration, thus it has complete information to parse it, figure out what needs to be done, and then do it using the INextProvider that it is assigned. The class ExpressionParser is used to convert the expression into a series of “nodes” that act on each item in the underlyingINextProvider and do the appropriate thing based on what it is (e.g. if it’s a WhereNode, it will have a predicate that it will run on each item).
  • If the method is something that returns a scalar (e.g. AnyAllFirst, etc.), NextProviderQueryProvider.Execute is called. In our case, we simply pass control to NextProviderEnumerator to enumerate as mentioned in the previous point, and then perform the appropriate action. We do this by getting an IEnumerable<T> that uses NextProviderEnumerator as its enumerator (and that is the NextProviderEnumerable class), and then calling the appropriate IEnumerable version of the IQueryable method that has been called. All of this is handled by the ExpressionExecutor class.

As of now, only the following methods are supported: AllAnyCastCountDistinctElementAtElementAtOrDefaultFirstFirstOrDefaultLast,LastOrDefaultLongCountOfTypeSelectSelectManySingleSingleOrDefaultSkipTake and Where. If you try to use any other methods, you will get an exception. Even within these methods, if you try to use a variant that is not supported, you will get an exception.

Next time, we’ll try our hands at a more real world implementation, i.e. a tiny, tiny ORM.

Writing your own LINQ provider, part 2

This is the second in a short series of posts on writing your own LINQ provider. A quick outline of the series:

  1. A primer
  2. Provider basics (this post)
  3. A simple, pointless solution
  4. A tiny ORM of our own

Provider Basics

In the previous post, we took a look at the two flavors of LINQ methods, i.e. the methods and classes around IEnumerable<T> and the methods and classes around IQueryable<T>. In this post, we expand upon what happens when you call LINQ methods on IQueryable<T>, and how you can use that to build your own provider.

Once you have an instance of IQueryable<T>, you can do one of three things with it:

  1. Enumerate it, using one of the following methods:
    1. Call a method such as ToListToArray or ToDictionary on it.
    2. Use it in a foreach loop.
    3. Call GetEnumerator() and then use the enumerator you get in the usual way.
  2. Call a LINQ method that returns a scalar result (this also results in the queryable getting enumerated) such as AnyFirstAllSingle, etc.
  3. Call a LINQ method (such as WhereSelectOrderBy etc.) that returns another IQueryable with some rules added that you can again do one of these very three things with.

For the first situation, IQueryable behaves just like any IEnumerable in that the GetEnumerator() method is called – so this is where you implement what you want to happen when the final enumeration happens. Usually, you do this by writing your own implementation of IEnumerator<T> for this purpose that you return from the GetEnumerator() method.

For the remaining two situations, the Provider and Expression properties of IQueryable<T> come into play. When you implement IQueryable<T>, you need to implement the getter for the Provider property to return an implementation of IQueryProvider<T> that does what you want.

In both cases, here is what the LINQ methods do:

  1. Create a lambda expression that represents the LINQ method call.
  2. Get a reference to the Provider for the target IQueryable<T>.
  3. For the first case, call Execute on the IQueryProvider<T> from step 2. For the second case, call CreateQuery on the ‘IQueryProvider` from step 2.
  4. The only thing that is different across different LINQ methods is the type parameters that are passed in, e.g. Any<T> will call Execute<bool> whileFirst will call Execute<T>. Similarly, Where<T> will call CreateQuery<T> while Select<TSource, TResult> will call CreateQuery<TResult>.

To drive the point home, here is the simplified source code for Where<T>:

public static IQueryable<T> Where<T>(
    this IQueryable<T> source, 
    Expression<Func<T, bool>> predicate)
    var currentMethodOpen = (MethodInfo) MethodBase.GetCurrentMethod();
    var currentMethod = currentMethodOpen.MakeGenericMethod(new[] {typeof (T)});
    var callArguments = new[] { source.Expression, Expression.Quote(predicate) };
    var callExpression = Expression.Call(null, currentMethod, callArguments);

    return source.Provider.CreateQuery<T>(callExpression);

And here is the simplified source code for Any<T>:

public static bool Any<T>(this IQueryable<T> source, Expression<Func<T, bool>> predicate)
    var currentMethodOpen = (MethodInfo) MethodBase.GetCurrentMethod();
    var currentMethod = currentMethodOpen.MakeGenericMethod(new[] {typeof (T)});

    return source.Provider.Execute<bool>(Expression.Call(
        null, currentMethod, new[] {source.Expression}));

Note how neither method body does anything specific to what a “Where” or “Any” operation should do. It just wraps that information in an expression and calls the appropriate method on the Provider. It is up to the provider to understand the expression (which is passed in as a parameter to bothCreateQuery and Execute) and perform the correct operation. This is why when you build a LINQ provider, it is up to you to write the translation logic for each LINQ operation as it relates to your data source, or write a fallback that says “this operation is not supported.”

Creating a new LINQ provider, then, can be boiled down to the following steps:

Step 1

Create a class that implements IQueryable<T> (say, YourQueryable<T>).

  1. There should be a way to construct this class and pass in some sort of an interface to the underlying data source to use (e.g. in NHibernate,session.Query<T> on the NHibernate ISession object does this).
  2. The call to GetEnumerator() should return your implementation of IEnumerator<T>, (say, YourEnumerator<T>). It should be initialized with the value of YourQueryable.Expression at the time of the call.
  3. The getter for the Provider property should return an instance of IQueryProvider<T> (say, YourQueryProvider<T>). The provider should have access to the underlying data source interface.

Step 2: Option 1

The logic to parse the final expression can go in YourEnumerator<T>. In this case, YourQueryProvider.CreateQuery simply returns a new instance ofYourQueryable<T> but with the Expression set to what is passed in to CreateQuery. The very first instance of YourQueryable<T> would then set theExpression to Expression.Constant(this). This way, when the time comes to enumerate and you get to YourEnumerator<T>, you have an expression that represents the complete call chain. That is where you then put the hard part of parsing that so that the first call to MoveNext does the right thing against the underlying data source.

Step 2: Option 2

Another option is to have a dumb YourEnumerator<T> and instead have a separate implementation of IQueryable<T> for each type of query operation to support (e.g. WhereQueryable',SelectQueryable’, etc.) In this case, the parsing logic is spread out across these classes, andYourQueryProvider.CreateQuery needs to examine the expression then and there return the correct type of IQueryable<T> with all the necessary information wrapped within. In any case, though, the expression as a whole must be parsed before enumeration happens.

Step 3

YourQueryProvider.Execute then needs to have logic that parses the expression passed in, figures out what needs to be done and return the result. This may involve enumerating the underlying IQueryable<T>. Going back to an ORM that is based on SQL Server, say, you would need to know to generate an WHERE EXISTS clause if you spot an Any in the expression.

Now, granted, all of this sounds pretty convoluted and can be hard to get a grip on without an example. So, we will do just that in the next post. We will start with a simple but pointless solution that does LINQ just for the sake of LINQ. Then, we’ll try to build a rudimentary ORM of our own.

Writing your own LINQ provider, part 1

This is the first in a short series of posts on writing your own LINQ provider. While LINQ is the best thing that ever happened to .NET, and using it is so much fun and makes life so much easier, writing your own LINQ provider is “complicated” to say the least (context- the LINQ interface to NHibernate, RavenDB or Lucene – those are all providers).

A quick outline of the series:

  1. A primer (this post)
  2. Provider basics
  3. A simple, pointless solution
  4. A tiny ORM of our own

A Primer

If you’ve used LINQ, you know there are two distinct syntaxes:

The “query” style:

from item in items
where item.Id == 2
select item.Name

And the “method chaining” style:

items.Where(item => item.Id == 2).Select(item ==> item.Name);

Except for the style, they’re pretty much the same in that the former is really syntactic sugar that compiles down to the latter. Now, the latter, as we know, is a series of extension methods that become available when you import the namespace System.Linq. Within this, though, there are two flavors of LINQ that are very different in terms of their internals:

  • IEnumerable<T> and everything that supports it
  • IQueryable<T> and everything that supports it

This means that when you call the same LINQ methods on an IEnumerable<T> versus an IQueryable<T>, very different things happen.

IEnumerable<T> and everything that supports it

These are simpler to use in that all the work has already been done as part of the .NET Framework. You simply use it. If you want to extend this to a data source of your own, you simply build an enumerator for it (e.g. if you wanted to slap LINQ on top of flat files, you could build a FileEnumerable that uses a FileEnumerator that, in turn, deals with a FileStream).

The extension methods are defined in System.Linq.Enumerable and the way they work is: each method, when called, wraps the IEnumerable it’s called on within a new implementation of IEnumerable that has knowledge of what operation is to be performed. These implementations are all private within theEnumerable class (e.g. Where on an array yields a WhereArrayIterator). When the final enumeration happens, the pipeline executes and gives you the desired result. The scalar-returning methods such as Any and First in this case are simple calls to the enumerator or foreach on top of the underlying enumerable.

All methods in this category deal with Func‘s when it comes to predicates or mapping functions that are passed in.

IQueryable<T> and everything that supports it

This is the focus of this series. You’ll notice that all methods in this category are defined within another class, System.Linq.Queryable and deal not withFunc‘s, but with Expression<Func<>>‘s when it comes to predicates or mapping functions that are passed in. You use this when you are working with a data source that has its own way of extracting data that either does not yield well to the IEnumerable way of doing things, or its own way of extracting data is just better-suited or superior than just enumerating away using IEnumerable. An example is relational databases, where rather than enumerating throw each row in a table and applying predicates or mapping to it, you’re better off running SQL.

The core idea here is to boil the method calls down into a lambda expression tree, then when the time comes to enumerate, parse that expression tree into something the underlying data source understands (using the relational database example, the expression tree needs to be parsed into SQL- that is what ORMs with LINQ providers such as NHibernate or Entity Framework do).

More on this to follow in future posts to come in this series.

Conditional jQuery Datepicker with AngularJS

I just find AngularJS directives so much fun. It is so satisfying to see them work. Recently, I came across a requirement where I had a text field bound to a property that could either be a date or text. I had a way of knowing which one it was, but if the property was a date, the text field would need to become a datepicker, and turn back into a normal text field if not. And no, not an HTML5 date control – an old-timy jQuery datepicker.

So, a simplified version of what the controller looked like:

var app = angular.module('app', ...);

app.controller('ctrl', function ($scope, ...) {
    $scope.isDate = false;
    $scope.dateOrText = '';

Here, dateOrText was bound to the text field and we had a way of knowing whether it was a date or not, represented in a simplified manner here by the boolean isDate. Given the HTML as follows:

<input type="text" ng-model="dateOrText"/>

The need was for this text field to become a jQuery datepicker whenever isDate becomes true and turn back to a normal text field when it becomesfalse.

An obvious application of directives, right? Here’s the naive solution:

app.directive('akDate', function() {
    return {
        restrict: 'A',
        link: function(scope, element, attrs) {
            scope.$watch(attrs.akDate, function(value) {
                if (value) $(element).datepicker();
                else $(element).datepicker("destroy");

The HTML would then look like:

<input type="text" ak-date="isDate" ng-model="dateOrText"/>

In plain English, the directive watches for the value of the ak-date attribute to change, and when it does – it uses the jQuery datepicker call to apply or remove “datepickerness” to the element.

One thing I did not catch though was the fact that just applying the datepicker is not enough. If you leave it like this, the rendering will work fine – however, the binding with the model will not work, i.e. picking a date will not update the value of dateOrText. The way that jQuery datepicker applies the selected text to the control is not picked up by Angular.

Fortunately, jQuery datepicker has an onSelect event that you can handle to put your own logic in that happens whenever a date is selected. We just need to use that to create an expression that assigns the value to the model, and then run it within Angular.

The complete solution then becomes:

app.directive('akDate', function() {
    return {
        restrict: 'A',
        require: 'ngModel',
        link: function(scope, element, attrs) {
            scope.$watch(attrs.akDate, function(value) {
                if (value) {
                        onSelect: function(dateText) {
                            var expression = attrs.ngModel + " = " + 
                               "'" + dateText + "'";
                } else $(element).datepicker("destroy");

Works like a charm!

Getting Functional With Perhaps

Ever since the introduction of LINQ, people have been trying all sorts of clever ways to get more functional constructs into C# to wrap away certain annoying procedural details that are part of the language because of its non-functional beginnings. One of the most annoying class of operations in this context are the TryX methods (e.g. TryGetValueTryParse and so on) that use out parameters and force you to break into statements what is otherwise a fluent sequence of calls.

Then there are others, even within LINQ, such as FirstOrDefault that keeps you from choking like First does – but then can’t tell the difference between something not being there versus something being there but being null (or the type-default for value types).

I recently stumbled across two instances of the clever things people do, viz. Brad Wilson’s Maybe<T> and JaredPar’s Option<T>. This inspired me to add some more goodness in and cook up something of my own, aptly named Perhaps<T>. I am making it part of the Commons Library, and you can find the source code here:

Here are a few examples of how this might be used:

It’s mostly obvious stuff, but I think this will go a long way in making my code less noisy.