Project Grid

This is part of a series of posts on Project Grid.

  1. Project Grid
  2. ThreeJS : Getting Started with ThreeJS
  3. ThreeJS : Creating a 3D World
  4. ThreeJS : Heads Up Display

Conceptual Overview

This is a multi-part series of blog posts on a project to create a web application providing a new way to organize and visualize content. The idea is to map the url – particularly the path, into grids that can contain different types of content. The content can be found based on its location (e.g. /something/something-else/?x=100&y=-250&z=300) which corresponds to a grid called “something-else” existing within another grid called “something” and at the 3D co-ordinate location [100,-250,300].

As such, out web application will render a visualization of 3D space in the browser and provide controls for navigating within that space as well as controls to travel between grids (navigation up and down the request path). It will also provide a way to visualize different types of content that can exist within a grid such as images, video, audio etc. These content types will be extensible so that new types can be added in the future.

This concept would provide a way to store a vast amount of content which can be consumed in a familiar and intuitive way. We can also provide features to help users locate content within grids that manipulate the 3D world to either transport the user to particular locations or to temporarily transport the content to them. Imagine for example being able to create a gravitational object that only affected content of a certain type within the current grid so that images, for example, were attracted to the users current location in 3d space temporarily.

Technology Stack

For this project, I will be building a REST service in ASP.NET Core that will use a document database to store the content that exists within a grid along with views to query that data based on the top level grid (e.g. the host), the specific grid (e.g. the path), and the co-ordinates (e.g. the query string).

The user interface will use WebGL for the 3D visualization and be implemented as a responsive experience. The interface will be optimized for desktop initially but the long term goal would be for this interface to work well across all devices that have a web browser and support WebGL so gesture support will be considered throughout.

Proof of Concept

This concept is an evolution of a previous 2D implementation which can be found here. You can tap items to interact with them or hold items to move them within the grid. Most items are grid links so you’ll notice that whilst at the root of the web application (/) there is a “Home” item at [0,0] that has no action whilst within a child grid (/contacts) there is a “Back” action at [0,0] that allows you to visit the parent grid – climbing up the path of the web application.

The source code for this 2D proof of concept can be found on GitHub.

 

 

Advertisements

The Specification Pattern

What is a Specification?

One of my favorite software development patterns is the specification pattern. This pattern provides a way of encapsulating business logic and helps to enforce the DRY principle.

As always with such things, a contrived example helps articulate the concept…

In a commerce system there are visitors and the business defines an active visitor as having used the system within the last 7 days and having placed an order within the last 30 days.

The specific logic is arbitrary. What is important is that we need to be able to define active visitors in numerous locations throughout our application and, should the business change their definition of an active visitor, we should be able to reflect the change in a single place within our code.

Enter the specification pattern which can be represented by the following interface:

public interface ISpecification<in T>
{
    bool IsSatisfiedBy(T subject)
}

Assuming we have services for checking system usage and order history we can implement this interface for our visitor example.

public class ActiveVisitorSpecification : ISpecification<Visitor>
{
    protected IUsageService Usage { get; set; }
    protected IOrderService Orders { get; set; }

    public ActiveVisitorSpecification(IUsageService usage, IOrderService orders)
    {
        Usage = usage;
        Orders = orders;
    }

    public bool IsSatisfiedBy(Visitor subject)
    {
        if(Usage.HasUsedInLastSevenDays(subject) && Orders.LatestOrderDaysAgo(subject) <= 30)
        {
            return true;
        }

        return false;
    }
}

As you can see from the example, we have encapsulated all the business logic within a single place and can now use this class throughout our application whenever we need to check if a visitor can be considered as being active.

// Get visitor
var customers = context.Visitors.Find(id);

// Initialize specification
var specification = new ActiveVisitorSpecification(usageService, orderService);

// Apply specification
if(specification.IsSatisfiedBy(c))
{
    // Do something with active visitor
}

Chaining multiple specifications

Whilst it’s great to encapsulate the business logic for active visitors within a single class, we might have been a little hasty. We didn’t stop to consider that the business has business logic to define other visitor groups such as recent visitors and recent customers.

The business defines a recent visitor as having used the system within the last 7 days and a recent customer as having placed an order within the last 30 days.

We can create a specification for each of these examples but now we are duplicating business logic across specifications instead. Still better than across the entire application but not a great improvement from what we originally had.

Instead we can use chaining to create discrete specifications for each of the specific examples and chain them together for the original definition of an active visitor being both a recent visitor and a recent customer.

Chaining is achieved by creating specifications that can apply boolean logic to other specifications. They implement the IsSatisfiedBy method just as before but their implementation is based on && (and), || (or), or ! (not) logic.

AndSpecification

public class AndSpecification<T> : ISpecification<T>
{
    protected ISpecification<T> Left { get; set; }
    protected ISpecification<T> Right { get; set; }

    public AndSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        Left = left;
        Right = right;
    }

    public bool IsSatisfiedBy(T subject)
    {
        return Left.IsSatisfiedBy(subject) && Right.IsSatisfiedBy(subject);
    }
}

As you can see above, the implementation is very straightforward. It just checks if both the left AND right specifications are satisfied by the subject.

OrSpecification

public class OrSpecification<T> : ISpecification<T>
{
    protected ISpecification<T> Left { get; set; }
    protected ISpecification<T> Right { get; set; }

    public OrSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        Left = left;
        Right = right;
    }

    public bool IsSatisfiedBy(T subject)
    {
        return Left.IsSatisfiedBy(subject) || Right.IsSatisfiedBy(subject);
    }
}

Once again, the implementation is very straightforward. It just checks if either the left OR right specifications are satisfied by the subject.

NotSpecification

public class NotSpecification<T> : ISpecification<T>
{
    protected ISpecification<T> Not { get; set; }

    public NotSpecification(ISpecification<T> not)
    {
        Not = not;
    }

    public bool IsSatisfiedBy(T subject)
    {
        return !(Not.IsSatisfiedBy(subject));
    }
}

This one is a little different as it simply checks that the specification is NOT satisfied by the subject.

Syntactic Sugar

Whilst this provides us a mechanism to chain multiple specifications together to create more complicated ones it isn’t pretty to instantiate these specifications – especially when nesting them within each other.

We can use static extension methods to add some syntactic sugar and make these really easy to use.

For example, for the AndSpecification we could have the following extension method:

public static ISpecification<T> And<T>(this ISpecification<T> left, ISpecification<T> right)
{
    return new AndSpecification<T>(left, right);
}

Now, we can replace our original ActiveVisitorSpecification with the following:

var recentVisitor = new RecentVisitor(usageService);
var recentCustomer = new RecentCustomer(orderService);
...
var activeVisitor = recentVisitor.And(recentCustomer);

We can even take it a step further and expose composite specifications (specification that are constructed by chaining others) within static methods so that we don’t duplicate the chaining in multiple places.

As with any pattern, the application of it depends on the individual developer.

Linq and IQueryable

The observant among you will have noticed that, whilst this is fine when we are dealing with individual customers, there may be times when we want to use a specification as a predicate for multiple customers.

This can be achieved by extending our original ISpecification<in T> interface.

public interface IWhereSpecification<T> : ISpecification<T>
{
    Expression<Func<T, bool>> Predicate { get; }
    IQueryable<T> SatisfiesMany(IQueryable<T> queryable);
}

A Predicate property exposes an expression that describes the specification using a predicate function whilst a new SatisfiesMany method takes an IQueryable<T> and returns an IQueryable<T> after having applied the specification.

Below is an abstract implementation of this interface:

public abstract class WhereSpecification<T> : IWhereSpecification<T>
{
    private Func<T, bool> _compiledExpression;
    private Func<T, bool> CompiledExpression { get { return _compiledExpression ?? (_compiledExpression = Predicate.Compile()); } }
    public Expression<Func<T, bool>> Predicate { get; protected set; }

    public bool IsSatisfiedBy(T subject)
    {
        return CompiledExpression(subject);
    }

    public virtual IQueryable<T> SatisfiesMany(IQueryable<T> queryable)
    {
        return queryable.Where(Predicate);
    }
}

Any subsequent concrete implementations can simply set the Predicate property.

We can also chain the specifications together as before by using a BinaryExpression when defining the subsequent predicate.

Now, when dealing with an IQueryable<T> you can reduce it using a specification and if you are using LINQ to SQL (e.g. Entity Framework) then the expression will be converted to a query meaning that you are only requesting a subset of data from SQL instead of requesting everything and reducing it in-memory.

Download from NuGet

If you want to use an existing implementation of the specification pattern you can do so by adding the Vouzamo.Specification NuGet package to your project.

Additionally, you can review the source on GitHub.

Web Components with ASP.NET Core 1.0

What are HtmlHelpers and TagHelpers?

With ASP.NET Core 1.0 comes MVC 6, and with the latest MVC framework there is a transition from HtmlHelpers to TagHelpers.

For those who aren’t familiar with HtmlHelpers, have a look in any MVC5 implementation and you’ll likely see:

@using(Html.BeginForm())
{
    ...
}

Anything beginning with @Html. is invoking a static extension method on a C# HtmlHelper class that resides within the System.Web.MVC namespace. HtmlHelpers are a really useful way to abstract logic away and avoid unnecessary duplication of mark-up within your views.

TagBuilders provide a similar abstraction but rather than rely upon the @Html. invocation they are implemented as tags – either by extending existing mark-up elements (such as <form>) or creating new ones (e.g. <custom-map>).

For an overview of TagHelpers see: https://docs.asp.net/en/latest/mvc/views/tag-helpers/intro.html

What are Web Components

Web components are custom DOM elements that encapsulate mark-up, styling, and JavaScript to be reused across multiple web sites. There are a number of different web component frameworks built against a common set of standards. One such example is Google Polymer.

Google Polymer also provide a number of prebuilt components in their Element Catalog.

screen2bshot2b2015-05-292bat2b11-02-192bpm

You can use existing elements as is, combine elements to create new ones by composition, or create custom elements from scratch.

How can a TagHelper be used with Polymer?

Let’s take an existing Polymer web component as an example. Google provide the google-map to add a map to your web page(s):

<google-map latitude="37.77493" longitude="-122.41942" fit-to-markers>

This is great if you have the latitude and longitude for a map available in your view model but what if you only want to expose the unique identifier of an address in your view and use a service to provide the latitude and longitude values?

One of the limitations of HtmlHelpers was the fact that they were static extension methods and as such didn’t compliment dependency injection. This often resulted in abusing the ViewData or TempData dictionaries that MVC provides to pass services into a view and subsequently into HtmlHelper(s) as a parameter.

TagHelpers are NOT static and are ideally suited to dependency injection meaning that you can combine the readability benefits of a HtmlHelper with the enforcement of single responsibility and dry principles (and testability) that dependency injection provide.

Creating a TagHelper

To create a new TagHelper you need to create a class decorated with a [HtmlTargetElement] attribute which is used to set the element/tag name and any required attributes. You can decorate properties with a [HtmlAttributeName] attribute to have them auto populated.

Dave Paquette has provided an excellent blog post on creating a custom TagHelper.

Note: Optional element/tag attributes can be omitted from the [HtmlTargetElement] attribute.

[HtmlTargetElement("custom-map", Attributes = AddressIdAttributeName)]
public class CustomMapTagHelper : TagHelper
{
    private const string AddressIdAttributeName = "address-id";

    private IAddressService AddressService { get; set; }
    [HtmlAttributeName(AddressIdAttributeName)]
    public string AddressId { get; set; }
 
    public CustomMapTagHelper(IAddressService addressService)
    {
        AddressService = addressService;
    }
 
    ...
}

Here, I have used constructor injection to wire up a dependency on IAddressService. This is a service that has a method called ResolveLocation that takes a string addressId and returns a LatLong:

public interface IAddressService
{
    LatLong ResolveLocation(string addressId)
}

public struct LatLong
{
    public double Latitude { get; set; }
    public double Longitude { get; set; }
}

Finally, you need to override the Process or ProcessAsync method of TagHelper and provide your implementation:

public override void Process(TagHelperContext context, TagHelperOutput output)
{
    var latlong = AddressService.ResolveLocation(AddressId);
 
    string content = $"<google-map latitude=\"{latlong.Latitude}\" longitude=\"{latlong.Longitude}\" fit-to-markers>";

    output.Content.AppendHtml(content);
}

We can reference our custom tag helper using the @addTagHelper Razor command. We can do this within the .cshtml templates we want to use it or make it available to all templates by adding it to our _GlobalImports.cshtml.

We can use the tag with the following mark-up:

<custom-map address-id="@Model.AddressId"></custom-map>

The above tag will render the following mark-up (with the latitude and longitude attributes dynamically populated):

<custom-map address-id="@Model.AddressId">
    <google-map latitude="37.77493" longitude="-122.41942" fit-to-markers>
</custom-map>

Benefits Recap

By using a TagHelper to generate the mark-up you have a single place to maintain it. Any future requirements that involve changing the way maps can be dealt with once rather than crawling through all the views and changing it manually.

Additionally we have reduced the effort required to re-use the custom-map element across our web application and reduced the potential for typographical mistakes.

Next Steps

This is a particularly simple (and contrived) example but you can use the same mechanism for lots of scenarios.

You should consider the following…

  1. How to replace the <custom-map> element with a <google-map>?
  2. How to toggle the fit-to-markers attribute?
  3. What if the AddressService throws an Exception? How to deal with failures.