Felix @ Planet

Version 0.0.4 of NodeAssets is available and I have have finally added in pure .NET compilers that can be used out of the box.

I am happy after many weeks of development to show to the world my awesome c# .net asset manager – Node Assets.

For this post you should already be familiar with using ninject for your DI needs. You would then be familiar with explicit binding and also possibly even the default convention based binding (using the Ninject.Extensions.Conventions package). We will take this a step further and see how we can define our own custom convention based bindings.

I have been working on a number of projects lately within nodejs and of course I have come across the requirement to store some data. Due to the loosely coupled nature of my data (a series of blog posts) I have gone down the NOSQL route, in particular using the redis library which is a nodejs wrapper for the redis server. In this post I hope to explore the advantages of a nosql database and make it easy using my own library redis-model.

Ok so I have been away for the last couple months working on a website for myself as a way to learn new things, and I thought it was about time to share some of my experiences. In this blog post I will be talking about nodejs, but more specifically to write a write a web app (from server to client) completely 100% in coffeescript.

Now that we’ve done all the hard work creating hooks and interfaces in previous posts creating the actual Selector is relatively simple.

In this post we are quickly going to discuss the need for a consistent way for our binding controls to let our selector class know exactly what to project. I will illustrate the problem by comparing the telerik controls RadComboBox and RadGrid.

In this part we will derive from ObjectDataSource to put in place a hook that our selector can latch onto. When delving into the workings of the ObjectDataSource it also became clear that we have to also override the ObjectDataSourceView that it uses. The location of the hook actually sits here.

When upgrading to use Entity Framework we are also in the process of trying to change all appropriate business layer calls to IQueryable – the main point of which was so that our UI can define specific projections on the data as it needs. Unfortunately we found no way that we could attach to a BL using some kind of DataSource and have this projection capability. So this post is out to create one.

In this post I’m going to talk about extending EF entities to encapsulate common functionality. For this particular case I will expand upon the concept in this blog post EF4 Part 2: EDM Inheritance Pains.