Quick NRest Video

This is a very quick video showing the work I've been doing with Nemerle, ASP.NET routing and VB 9 XML literals.
I'm trying to find the most efficient way to create RESTful web applications. I'm willing to use all the tools in the box and even make my own to achieve this.

Wednesday, July 02, 2008 10:19:24 AM (GMT Standard Time, UTC+00:00)      Comments [1]  .net | nemerle | REST | screencast | vb.net

Inject app settings from config

When unit testing a class that relies on app settings you don't want to be setting up web.config to get it running. I realised today that app settings are a dependency of a class. Therefore they must be injected by the IoC container. I'm using Ninject...

I have this in my web.config:
<appSettings> <add key="bar" value="1234" /> </appSettings>

I want to inject that value into a class constructor as below:

class Foo {
  public Foo(AppSetting bar)
  { ... }
}

AppSetting is a simple wrapper around a string:
class AppSetting {
  public AppSetting(string value) { Value = value; }
  public string Value { get; private set; }
}

I then configure Ninject with:
Bind<AppSetting>().ToProvider<AppSettingProvider>();

Where AppSettingProvider is:
class AppSettingProvider : Ninject.Core.Creation.IProvider
{
    public object Create(Ninject.Core.Activation.IContext context)
    {
        return new AppSetting(WebConfigurationManager.AppSettings[context.Target.Name]);
    }

    public Type GetImplementationType(Ninject.Core.Activation.IContext context)
    {
        return typeof(AppSetting);
    }

    public bool IsCompatibleWith(Ninject.Core.Activation.IContext context)
    {
        return WebConfigurationManager.AppSettings[context.Target.Name] != null;
    }

    public Type Prototype
    {
        get { return typeof(AppSetting); }
    }
}

The end result is a class that can be trivially unit tested, since it never calls the configuration API directly. Also, there was no need to create some complex abstraction around the API just to enable unit testing. In the future I can even change how and where app settings are stored (maybe using a database for example) all I'd have to do is make a new provider.

Ninject - in a word: awesome!

Tuesday, June 24, 2008 11:13:21 AM (GMT Standard Time, UTC+00:00)      Comments [0]  

Hasic Demo

A demo website using my Hasic view engine for ASP.NET MVC.

HasicDemo.zip (275.95 KB)

Saturday, May 10, 2008 4:37:41 PM (GMT Standard Time, UTC+00:00)      Comments [0]  .net | vb.net | web | hasic

Ninject Open Generic Types

I have started using Ninject a dependency injection framework for .NET. I find it very easy to use and recommend that people take a look.

Something in particular that I found useful is the ability to bind open generic types.

class Program
{
    static void Main(string[] args)
    {
        var k = new StandardKernel(new MyModule());

        var di = k.Get<Data<int>>();
        di.Content = 14;
        Console.WriteLine(di.Content);

        var ds = k.Get<Data<string>>();
        ds.Content = "hello";
        Console.WriteLine(ds.Content);
    }
}

class MyModule : StandardModule
{
    public override void Load()
    {
        Bind(typeof(IData<>)).To(typeof(Data<>));
    }
}

class Data<T> : IData<T>
{
    public T Content { get; set; }
}

interface IData<T>
{
    T Content { get; set; }
}

Very cool!

Tuesday, April 29, 2008 6:36:59 PM (GMT Standard Time, UTC+00:00)      Comments [2]  .net | c# | ninject | programming

Test-Friendly Snooze

After beginning to use Snooze on a real project I realised it needed to be more extensible and more testable. So I re-wrote it!

The new code is now in the trunk: http://svn2.assembla.com/svn/snooze/trunk

A key extensibility point is the "ResourceContext" class. Before a resource is invoked, it's ResourceContext is initialised with relevant data such as HttpContext, invoke verb, GET view and file type. The base Resource class allows sub-classes to specify a particular ResourceContext sub-class, by the use of a generic type parameter. So when using Snooze in a web project it is easy to define extra context data that is always available to any resources. Instead of adding properties to a Resource class, the use of a context object allows data to be easily shared between a sub-resource and it's parent resource chain.

A Snooze resource also has a ResourceFactory object. The type of this is also generically typed so that a web project can provide a customized factory.

These changes make it easy to do things like test that a resource creates sub-resources (through the factory).

Monday, March 24, 2008 5:19:52 PM (GMT Standard Time, UTC+00:00)      Comments [0]  

Testing Controller RenderView

I've seen people testing that RenderView is called by a controller by inheriting into a "testable" controller. Madness!

RenderView is just a convenience method that calls to IViewEngine, so why not just test expectations on that with a mock? We basically want to test that the correct ViewContext is sent to the RenderView method of the view engine.

This is my test:

[TestFixture]
public class HomeControllerTests : ControllerTestsBase<HomeController>
{
    public override HomeController CreateController()
    {
        return new HomeController();
    }

    [Test]
    public void Renders_Index()
    {
        var render = ExpectRenderView();

        Controller.Index();

        Assert.That(render.Data.ViewName, Is.EqualTo("Index"));
    }
}

I don't think we can get more straight forward than that!

This is my test base class:
(I'm using Moq as the mock framework.)

public abstract class ControllerTestsBase<T>
    where T : Controller
{
    public T Controller;
    public Mock<IViewEngine> ViewEngine;

    [SetUp]
    public virtual void SetUp()
    {
        Controller = CreateController();
        ViewEngine = new Mock<IViewEngine>();
        Controller.ViewEngine = ViewEngine.Object;

        Controller.ControllerContext = new Mock<ControllerContext>(new Mock<HttpContextBase>().Object, new RouteData(), Controller).Object;
    }

    public abstract T CreateController();

    public RenderCall<ViewContext> ExpectRenderView()
    {
        var render = new RenderCall<ViewContext>();
        ViewEngine.Expect(v => v.RenderView(It.IsAny<ViewContext>()))
            .Callback(new Action<ViewContext>(render.Set));
        return render;
    }
}

The RenderCall class provides a place to receive the view context that is passed.

public class RenderCall<T>
{
    bool _called;
    T _data;

    public T Data
    {
        get
        {
            if (!_called) throw new InvalidOperationException("View was not rendered.");
            return _data;
        }
    }

    public void Set(T data)
    {
        _data = data;
        _called = true;
    }
}
Monday, March 24, 2008 4:08:16 PM (GMT Standard Time, UTC+00:00)      Comments [0]  .net | mvc | thinking | web

VB.NET 9 as an HTML View Engine

VB.NET 9 introduces a clean syntax for expressing XML data. XHTML is XML so why not use VB.NET to generate it, instead of ASPX pages? People are creating view engines for the new ASP.NET MVC framework. How about a view engine that uses VB.NET XML literals?

The benefits to this approach include full intellisense and access to a the full VB.NET language when creating HTML.

I see a view as a function from some data to an XML element (the <html> element):

Function CustomersPage(ByVal title As String, ByVal customers As IEnumerable(Of Customer)) As XElement
    Return _
        <html>
            <head>
                <title><%= title %></title>
            </head>
            <body>
            <%= From customer In customers Select _
                <div id=<%= customer.LastName %>>
                    <h1><%= customer.FirstName %></h1>
                </div> %>
            </body>
        </html>
End Function

The important change from ASPX is that this is HTML in Code, rather than Code in HTML. As a result less "automagical" behaviour is required; It's just a function! This means AJAX features like "partial rendering", where a section of page needs to be updated, can be expressed by just calling a function that returns a <div> element. That same function can be used by the full HTML page function too.

ASPX "usercontrols" become simply functions as well. ASPX Master Pages are functions that have arguments for "placeholders" that get inserted into an template HTML page. Instead of having to reinvent a bunch of programming language concepts inside ASPX, we can just use a programming language that now support XML!

The only down side to this approach is we lose the IDE visual designer support. However, I find viewing an ASPX page that contains even simple conditional data rendering next to useless. I'd rather keep IE open and just refresh the page to see changes.

I am yet to embrace the MVC framework. I am waiting to see if the next release can better support Snooze framework ideas. However, there's no reason I can't use this VB XML magic in Snooze as it current is.

Tuesday, February 19, 2008 12:12:17 PM (GMT Standard Time, UTC+00:00)      Comments [0]  .net | html | thinking | vb.net | web | xml

Async WebRequest using LINQ syntax

Wes Dyer's paper http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx has a great introduction to using Monads in C# and specifically how to create a continuation Monad that leverages the LINQ syntax.

After a lot of re-reading and coding, I managed to construct an asynchronous web request program.

UPDATE: Added Select<T> method for the monad so "let" syntax works.

class Program
{
    static void Main(string[] args)
    {
        var requests = new[]
        {
            WebRequest.Create("http://www.google.com/"),
            WebRequest.Create("http://www.yahoo.com/"),
            WebRequest.Create("http://channel9.msdn.com/")
        };
        var pages = from request in requests
            select
                from response in request.GetResponseAsync()
                let stream = response.GetResponseStream()
                from html in stream.ReadToEndAsync()
                select new { html, response };

        foreach (var page in pages)
        {
            page(d =>
            {
                Console.WriteLine(d.response.ResponseUri.ToString());
                Console.WriteLine(d.html.Substring(0, 40));
                Console.WriteLine();
            });
        }

        Console.ReadKey();
    }
}

The actual web requests are deferred until the for loop invokes each "page" method. If you run the example a few times, you see that the results come back in a non-deterministic order, as expected with concurrent asynchronous operations. In addition, the web response stream is read asynchronously. So the main thread is never blocked - in fact that's why we need the Console.ReadKey() at the end, to stop the process ending before the results come back!

I had to change the type of the continuations from what Wes used. Instead of Func<T, Answer> I am just using Action<T>. The following code implements the continuation monad and the additional WebRequest and Stream extension methods.

delegate void K<T>(Action<T> c);

static class Continuations
{
    public static K<T> ToContinuation<T>(this T value)
    {
        return c => c(value);
    }

    public static K<U> SelectMany<T, U>(this K<T> m, Func<T, K<U>> k)
    {
        return c => m(x => k(x)(c));
    }

    public static K<V> SelectMany<T, U, V>(this K<T> m, Func<T, K<U>> k, Func<T, U, V> s)
    {
        return m.SelectMany(x => k(x).SelectMany(y => s(x, y).ToContinuation<V>()));
    }

    public static K<U> Select<U, T>(this K<T> m, Func<T, U> k)
    {
        return c => m(x => c(k(x)));
    }

    public static K<WebResponse> GetResponseAsync(this WebRequest request)
    {
        return send => request.BeginGetResponse(result =>
        {
            var response = request.EndGetResponse(result);
            send(response);
        }, null);
    }

    public static K<string> ReadToEndAsync(this Stream stream)
    {
        return send =>
        {
            byte[] buffer = new byte[1024];
            StringBuilder sb = new StringBuilder();
            Func<IAsyncResult> readChunk = null;
            readChunk = () => stream.BeginRead(buffer, 0, 1024, result =>
            {
                int read = stream.EndRead(result);
                if (read > 0)
                {
                    sb.Append(Encoding.UTF8.GetString(buffer, 0, read));
                    readChunk();
                }
                else
                {
                    stream.Dispose();
                    send(sb.ToString());
                }
            }, null);
            readChunk();
        };
    }

}

I imagine we will see something like this come out of the Volta project soon. Hopefully, it will form a generic asynchronous library that we can all use with anything that implements the Begin/End Invoke pattern.

Monday, January 14, 2008 1:22:13 PM (GMT Standard Time, UTC+00:00)      Comments [0]  

Snooze - A REST Framework for .NET

I have released an initial version of Snooze. http://www.assembla.com/wiki/show/snooze

Snooze is an REST framework for ASP.NET. It puts the emphasis back on the "R" of URI. The Resource concept is a first-class citizen.

In Snooze you create a resource class that defines the URI template and HTTP methods it supports.

[HttpResource("customer/{CustomerId}")] // Defines the URI template for this resource
public class CustomerResource : HttpResource // A useful base class that implements IHttpResource
{
    // URI template variables are mapped to properties
    public int CustomerId { get; set; }

    // Handles the HTTP GET method
    public override void Get()
    {
        RenderView("Customer", Data.Customers[CustomerId]);
    }

    public override void Put()
    {
        // Read data sent in Request body and update the customer...
    }

    public override void Delete()
    {
        // Delete the customer...
    }

    // HTTP POST can also be provided if it makes sense for the resource.
}

This will mean a URI like "http://yourserver.com/customer/42" will invoke the Get method of an instance where CustomerId equals 42.

What about creating a new Customer?

Well you don't have an ID for the new customer since that is probably created in the database. Therefore you don't know what the URI will be yet. The correct solution here is to POST the new customer data to a CustomerList resource, with URI "/customers".

Alternative GET Views

You can create extra GET methods:

[HttpGetView("edit")]
public void GetEdit()
{
    RenderView("CustomerEdit", Data.Customers[CustomerId]);
}

This results in URIs like "/customer/42?edit"

File Extensions

To support different file formats, such as XML and JSON use:

[HttpGetFile(".xml")]
public void GetEdit()
{
    SendXml(Data.Customers[CustomerId]);
}

This will be mapped to by URIs like /customer/42.xml

Sub-Resources

Resources can be naturally nested. For example, a Customer may have Orders.

[HttpSubResource(typeof(CustomerResource), "order/{OrderId}", true)]
public class OrderResource : HttpSubResource<CustomerResource>
{
    public int OrderId { get; set; }
    // ...
}

In this sub-resource, you can have access the parent CustomerResource, using the strongly-typed, ParentResource property.

URIs for this sub-resource will look like: "/customer/42/order/123"

The "true" argument in the attribute, specifies that parent query string parameters are added to this sub-resource URI as well. So a parent with URI template "customer/{CustomerId}?foo={Foo}" will yield sub-resource URI template "/customer/{CustomerId}/order/{OrderId}?foo={Foo}".

Nullable Resource Properties

Imagine a blog posts resource. Its URI could be /posts/{Year}/{Month}/{Day} to get all the posts on a given date. Now what if you want to naturally get the posts for a whole month, year, or ever?

By declaring the properties as nullable, e.g. "int?" in C#, Snooze will also map the "reduced" URIs to your class. You can then test the properties for "null" and return data accordingly.

Reusing Resource URIs

When rendering an HTML view it is likely you will need to link to other resources. Instead of manually typing the URI string, you can call the Uri property available on HttpResource.

new CustomerResource { CustomerId = 42 } .Uri

Resource Areas

Snooze supports resource "areas". These let you map all the resources of a given assembly into a given sub-path. If, for example, a third-party blogging package was built using Snooze you could include it as follows:

web.config:

<configuration>
  <restAreas>
    <area path="" assembly="MyWebsiteAssembly"/>
    <area path="blog" assembly="SomeCompany.BlogEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
  </restAreas>

So the blog resource URIs would look something like: http://mysite.com/blog/posts/2007/01

HTML Form Support

HTML forms only support GET and POST. To overcome this limitation you can include: <input type="hidden" name="__method" value="DELETE" /> to override the name of the HTTP method used by Snooze.

Feedback

This project came mostly out of curiosity! I wanted to see if REST could be done better under ASP.NET. The code is still very new (less than two days!) It is open source (BSD license) and available via SubVersion. A quick sample project is also provided.

Let me know what you think. Everything is open to changes. Join the assembla project if you would like to contribute your help.

Thursday, January 10, 2008 9:42:04 PM (GMT Standard Time, UTC+00:00)      Comments [1]  .net | c# | programming | REST | web