asp.net

.Less is featured on the new ASP.NET site

Erik van Brakel — Thu, 11 Mar 2010 12:31:24 GMT

I’ve recently had a lot less (pun not intended) time to spend on .less, but I do keep track. Scott Hanselman mentioned the new ASP.NET site went live, and it looks good!

What REALLY caught my eye is the section on open source projects it has, under the ‘community’ tab. It has a lot of nice, established projects mentioned, like Nhibernate, Subtext, Spark and a lot of others. What really amazed me is that .less is mentioned! If you scroll down to the Misc section, there it is! Seems like I really have to schedule my work better so I can invest more time in .less again. That’s a good thing, right?

ASP.NET MVC: Tricky modelbinding feature (?)

Erik van Brakel — Wed, 25 Nov 2009 23:24:58 GMT

I just ran into a situation which could lead to very annoying latent bugs in your web application. Observe the following code.

The view:

<form method="post" action="Photo/Save">
  <input type="text" name="Photo" />
  <input type="text" name="Title" />
</form>

The Controller action:

public ActionResult Save(PhotoDTO photo)
{
    // do something with the object
    return RedirectToAction("Index");
}

The class:

public class PhotoDTO
{
    public string Photo { get; set; }
    public string Title { get; set; }
}

At first sight, there’s nothing wrong with this code. You’d say when the form is posted, the PhotoDTO object gets automatically created by the default modelbinder in the framework, and you’ll be able to do what you want with the PhotoDTO (like, errr, save it?). However, what REALLY happens is that the parameter photo will be null. Now I’ll give you a moment to realize what’s happening.

…

Alright, that’s enough. What’s happening is that the field with the name ‘Photo’ is getting precedence over binding the whole thing to the PhotoDTO class. So let’s say I put the value “SomePhoto” in the textbox, it’ll try to bind that value to an object of the type PhotoDTO. That fails, so it returns null.

I’m not sure it’s intended, I’m assuming it’s just a side-effect of what needs to be done to be able to bind to complex models as well as simple parameters. Either way, if you’re not aware of this quirk you’re in for a surprise if you accidentally run into this!

The conclusion

I asked Phil Haack on twitter if this was intended. He said:

@erikvanbrakel yes, by design. BTW, your PHotoDTO needs to make properties public too.

So there you have it, keep this in mind when writing your code, it’s not going anywhere, it’s as intended!

Note: I corrected the PhotoDTO, it was missing the ‘public’ access specifiers.

About the .Less project

Erik van Brakel — Sun, 22 Nov 2009 21:30:37 GMT

I had a short twitter conversation with Aaron Jensen on the decisions we made developing .Less. As I’ve blogged about before, for me personally it was more of a learning project than something with a set goal, at first. That aside, I had one thing in mind: being able to use less during development, without having to worry about it, add a handler and go!

Less.Net, v0.1

My first solution was to simply install ruby and wrap the whole system call in a HttpHandler. Very clunky, but it worked! I blogged about this a while ago: Using LessCSS in an ASP.NET site.

I got it working, tried to implement it in my web project, and ran into another problem: It’s SLOW. Could be solved with caching, but in development I generally dislike that. It presents another point of failure which can take quite some time to figure out.
Another point was the fact that ruby should be installed. If you’re familiar with the .NET ecosystem you’ll know that a lot of people just want to deploy a single DLL and be done with it. Installing ruby, getting it to install a gem and then using that in your build process is quite a bit of work you want to avoid, if at all possible. That’s two problems I wanted to solve.

Being influenced a bit by the things I saw coming by on twitter (Linq to NHibernate to be exact) I looked into ANTLR for the parsing, which was simply an interesting technique to learn. I got a working prototype for a simple less file, published it, and got in touch with Daniel and Chris, with which we formed the current .Less project. Before joining up, Daniel gave IronRuby a shot for implementing the ruby gem in .NET, but it turned out to be too painful to deploy and too slow.

Perhaps with the next version of the CLR IronRuby will be a good option for Less, but honestly, I don’t expect that to be mainstream for at least another year.

Less.Net and nLess become .Less

After a few talks via skype, we decided to work on Chris’ codebase, called nLess at that moment. The reason why is that the grammar style he used is very similar to the ruby treetop grammar, which makes porting new language features quite painless. Also, I ran into a few problems with my grammar which would require quite a bit of rewriting of the grammar.

We’re not aiming for creating our own dialect, we want to adhere their standard as much as possible. The general idea is to introduce the less syntax in the .NET world, in such a way that it’s recognizable for the average .NET developer. That’s why having a grammar which is easily ported from one to the other is of great value to the project.

The future

While we do want to adhere to the ‘official’ syntax, we’re not bound to the functionality the ruby gem offers. We’ve got a few cool ideas we can do, but not before we’ve got a more edge cases of the current implementation covered. We’re also looking into creating a Visual Studio plugin, to, again, reduce the friction of using less in your ASP.NET solutions.

Another thing that’s on our agendas is to create more viable specs to test. We’re currently using the somewhat outdated ruby specs, which are generally very big umbrella specs. They also don’t exactly do what you’d expect. Hopefully we can create a common set of specs both the ruby gem as our .NET DLL, as the PHP version that’s around there can use. That way it won’t matter which environment you use, your less files will always work.

Well, that’s the story about .Less and how it came to be. If you’re interested in the project, I invite you to go to http://www.dotlesscss.com/ and try it out. We’re usually quite fast on the response to our google group, so if you want to ask anything, feel free to do so.

ASP.NET MVC: Access an action only by ajax

Erik van Brakel — Mon, 05 Oct 2009 10:00:00 GMT

In a standard ‘web 2.0’ (god, I hate that buzzword) web application, you’ll often have ajax calls to your code. I prefer using jQuery, but any method will do. A proper ajax request will set a header value in the HTTP GET request, and ASP.NET is a good boy and catches that. By checking if the IsAjaxRequest() method on the request returns true.

This feature can be utilized for something I like to do on my ajax-exclusive controller actions: restrict access in such a way that only ajax requests can call the action. Other actions will get a 404, which effectively means the action will never be indexed by search engine crawlers, for one. To do this, I think a good way is to follow the convention set by the framework itself on restricting the actions to certain verbs (GET, POST): use an attribute on the method!

So how do we do this? It’s very simple actually. ASP.NET MVC provides a bunch of extension points, and this is one of them. There’s an class in the framework called ‘ActionMethodSelectorAttribute’, which contains only one method, which returns true if the call is permitted, false if it isn’t. On each call to an action, the framework checks for any attributes on the method which implement this class, and makes sure all of these return true. Simply put: we’ll implement the class in such a way that it will return true when the action is called via ajax:

public class AjaxRequestAttribute : ActionMethodSelectorAttribute
{
    public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo)
    {
        return controllerContext.HttpContext.Request.IsAjaxRequest();
    }
}

I told you it was simple. Now you can use this attribute in your controllers, as such:

public class HomeController : Controller
{
    [AjaxRequest]
    public ActionResult Index()
    {
        return View();
    }
}

Yes, this is a silly example. It demonstrates the functionality though. When you go to /Home via your web browser now, you will get a 404, page does not exist. However, when you call /Home via ajax, you’ll get the HTML output from the view returned. That’s it.

ASP.NET MVC: Common viewdata

Erik van Brakel — Thu, 01 Oct 2009 23:50:53 GMT

One issue I’ve heard a few times already when explaining ASP.NET MVC to others is how to deal with common viewdata which should be available to every page. Sure, you can simply add it to the viewdata in each and every controller action you call, but that’s a horrible violation of the DRY (Don’t Repeat Yourself) principle. It’s also very error-prone, because you’re very likely to forget to add it some time or another.

A more elegant solution to the problem is to have a base controller class which you will use for all your controllers. This is a no-brainer, really, as there’s almost always a case which warrants this solution.

A more elegant solution indeed!

The default Controller class used in ASP.NET MVC offers some interesting hooks for changing the behavior of your application. The ones we’re interested specifically are the event hooks, methods called ‘On…()’. In this case, we’ll make use of the OnActionExecuting() method. This method is called right before an action is executed. What we’re going to do is add a few things to the viewdata collection, so we can guarantee this data to be available at every point in the application.

First, let’s create a base class with the method mentioned overriden:

using System.Web.Mvc;

namespace CommonViewDataSample.Controllers
{
    public abstract class ControllerBase : Controller
    {
        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            ViewData["MyViewData"] = "Something common here!!!";
            base.OnActionExecuting(filterContext);
        }
    }
}

Take note of setting the data in viewdata collection, which will now be available in any view you request.

Now, going by the sample ASP.NET MVC project that’s generated whenever you create a new MVC project, we’ll adapt the controllers in that project to make use of this base class:

In Controllers/HomeController.cs

public class HomeController

becomes

public class HomeController : ControllerBase

In Controllers/AccountController.cs

public class AccountController

becomes

public class AccountController : ControllerBase

Now you're set! In ANY view, masterpage, partial view or whatever, you can now use ViewData["MyViewData"] just like you'd use any other viewdata. There are more ways to reach this goal, but this is the simplest form other than putting your viewdata in every controller action, so I figured I’d touch this first. I will write about other methods do this later, so stay tuned!