Lately I’ve been playing around with a cool little library called DotLiquid, a templating system ported from the Ruby Liquid library, originally created by the folks at Shopify. The beauty of this templating system is that it is very designer friendly, and is uber easy for anybody to get to grips with. Check out this little snippet and see for youself:

<ul id="products">
  {% for product in products %}
    <li>
      <h2>{{ product.title }}</h2>
      Only {{ product.price | format_as_money }}
      <p>{{ product.description | prettyprint | truncate: 200  }}</p>
    </li>
  {% endfor %}
</ul>

Simple right? One of the other great features of DotLiquid is also how restrictive it is. That might sound like it should be a negative, with most people thinking flexibility is the key, but in reality it means template development is secure and template designers can only have access to what you want them to.

Whilst playing around with DotLiquid, I thought it would be cool if it could be used as an ASP.NET MVC ViewEngine. After a bit of a search though, I wasn’t able to find one. There were view engines written for Nancy and Jessica, but nothing for ASP.NET MVC. So like any respectable developer, I decided to write one :)

DotLiquid.ViewEngine

To get started, either download the view engine from the NuGet gallery, or just install it directly in an ASP.NET MVC project by issuing the command:

PM> Install-Package DotLiquid.ViewEngine

Once you have it installed, you are pretty much ready to rock. Simply create your views in your views folder as per normal, but with a .liquid file extension (you’ll need to prefix your partials / masters with an ‘_’ as per the DotLiquid requirement) and just start using the liquid syntax. The rest should just work automatically.

One other important note, and related to the deliberate restrictive nature of DotLiquid, is to make sure that any models passed down to your view, must be ILiquidizable. The simplest way to do this, is to have your ViewModels to just inherit from the DotLiquid Drop class. The ILiquidizable interface simply lets DotLiquid know which properties should be available to the template designer via the Liquid syntax.

It’s as simple as that.

For more information on the Liquid syntax, checkout the documentation on the DotLiquid and Liquid sites, and if you give the view engine a try, be sure to let me know if you have any problems / suggestions. And lastly, if you’d like to have a poke around the code for the view engine, you can find it now over on bitbucket.

So yesterday was the first ever Digital Barn, a local, free event organized by Matt Watson and Kimb Jones in conjunction with Barnsley DMC, and I have got to say, it was a fantastic do.

As a developer who has been working on the web for over 12 years now, it can become very easy to slip into a comfort zone. I like to think I’ve read all the right articles, and that what I produce is good quality code. And for the most part, it generally is. But there is always room for improvement. As we grow as designers / developers, it’s inevitable that we become specialists in certain areas, and start to fall behind in others. For me, that is when the importance of local events can really shine.

It’s a chance for you to come out of that comfort zone, and to challenge what you think you already know. It’s a chance for you to checkout subjects that you might not ordinarily look into. And it’s a chance for you to get out and meet others with similar interests.

The Digital Barn was a great example of this, with talks on various subjects, with folk from near and far turning out. For me personally, there were 2 talks which really challenged my existing conceptions and really inspired me to make some changes. Harry Roberts, Breaking Good Habbits and Craig Burges, The Mad Scientists of the Information Superhighway.

Harry’s talk discussed some interesting concepts about CSS and creating more maintainable websites by thinking more semanticly and Craig’s talk about reigniting the magic of the information superhighyway by encoraging designers and developers to spend more time working on those fun ideas we all have, but never do anything about, really rang true with me.

So it’s thanks to events like the Digital Barn that we can all take that step out of our comfort zones and open our selves up to ideas we may not have thought of without them.

So with that I’d like to give a big thanks to Matt and Kimb for organizing the event, and I encourage you to search out a local event near you and see if you can find unexpected inspiration. I for one can’t wait for the next one.

For anybody who doesn’t know, working at Umbraco HQ, every Fridays is Freedom Fridays, in which the whole team take a break from their usual projects, and spend the day doing some personal development.

Having spent a fair bit of time playing around with Knockout.js recently (If you haven’t done already I urge you to checkout the Introduction to Knockout JS talk I gave at the Umbraco UK Festival back in November), I thought I’d have a go at writing my own plugin for it.

With that in mind, I introduce to you, Knockout Hotkeys.

Knockout Hotkeys is a custom binding plugin for Knockout that allows you to define global hotkeys for elements in your design, allowing you to effectively develop keyboard driven interfaces.

You can define a hotkey by using one of three binding attributes

  •     hotkeydown
  •     hotkeyup
  •     hotkeypress

The actual syntax is then as follows (NB: Modifier keys should be defined in alphabetical order, ie alt+ctrl+shift):

<input type="text" data-bind="hotkeydown: { shift1 : doSomething }" />

If you would prefer your key combinations to be a little more readable, you can also define them in the following format:

<input type="text" data-bind="hotkeydown: { 'shift+1' : doSomething }" />

You can also register multiple hotkey combos within a single binding statement as follows:

<input type="text" data-bind="hotkeydown: [{ 'shift+1' : doSomething }, { 'shift+2' : doSomethingElse }]" />

In addition to the key combination option, you can also provide an if statement which must be met to allow the hotkey to trigger:

<input type="text" data-bind="hotkeydown: { 'shift+1' : doSomething, if: currentItem() == $data }" />

Lastley, you can also use a more verbose syntax to allow the creating of dynamic key combinations:

<input type="text" data-bind="hotkeydown: { key: 'shift+' + $data.substr(0,1).toLowerCase(),  do: doSomething }" />

If you’d like to give Knockout Hotkeys ago, you can grab it now over on bitbucket.

All in all, it’s been a lot of fun creating this plugin. The more I explore Knockout, the more I love it. From the beautiful syntax, to the amazing documentation. I wish more libraries could be like this.

Follow

Get every new post delivered to your Inbox.