Web API Namespaces vs MVC Namespaces

tl;dr: You should never have references to System.Web.Mvc.* in an ApiController.

One thing that took me longer than I’d care to admit to realize when working with Web API and ApiController is that Web API has its own namespace to do a lot of the stuff I was used to System.Web.Mvc doing.

So, for example, there’s a System.Web.Mvc.HttpPostAttribute class that you’d use to decorate a controller action to tell it to accept HTTP POST requests.

If you’re trying to do that on an ApiController action, you’ll want to use System.Web.Http.HttpPostAttribute.

The code ends up looking the same, mostly, though, because instead of including using System.Web.Mvc; at the top, you’ll have using System.Web.Http, and you’ll end up writing the attribute as just [HttpPost].

This doesn’t just apply to those attributes, either. Web API uses that System.Web.Http stuff for action filters, configuration, and plenty of other stuff. You should never need to include System.Web.Mvc.* for anything in an API controller.

Simple JS Prototype Example

This is some boilerplate code I sent out recently to describe the JS prototype code I’d been writing:

// create a global MyClass object, intialized to the result of this anonymous, self-executing function
var MyClass = (function() { 

   // constructor function, intializes stuff
   function MyClass($el, options) {
      var self = this;
      self.options = options;
      self.$el = $el;
   } 

   // put functions on the prototype for the constructor function
   MyClass.prototype = {
      myPublicFunction: function() {
         this.$el.doSomething();
      }
   } 

   // return the constructor function, so the MyClass outside of this closure becomes a function
   return MyClass;
});

You can then create an instance of MyClass like this:

var myClass = new MyClass($("#element"), myOptions);

With this pattern, not only can you create multiple instances of the class, but they’ll inherit the same prototype, which means all those prototype functions only get created once, not once for each object you create.

It’s also worth pointing out that it’s a JS convention to only capitalize function names when they’re meant to be used with the “new” keyword, to be treated as objects.

Fun times.

“var” and JS Global Scope

If you assign a value to a variable in javascript without first declaring that variable with var, it goes into the global scope.

So if, within a module, I do something like this:

var MyModule = function() {
   var _public = {};

   var doSomething = function() {
      alert("foo");
   };

   doSomethingElse = function() {
      alert("bar");
   };

   _public.init = function(options) {
      _public.options = options;
   }

   return _public;
} ();

Then the following things are true:

  • _public lives inside the scope of MyModule.
  • _public.init is inside public, so it’s within MyModule, and I can call MyModule.init() to invoke it.
  • doSomething is a private function in MyModule.
  • doSomethingElse is a function in the global scope.

We want to minimize the amount of junk that’s in the global scope, lest we run into some very confusing bugs resulting from naming collisions.

And this has been today’s Fun with Javascript.

Oh, hi

So, welcome to veryfancy.net. I threw this site up after dinner one evening, installing Orchard CMS locally, copying the Theme Machine theme, tweaking it, and pushing it all to my shared hosting provider. Pretty simple, except it turned out that Orchard needs full control of the App_Data folder. I needed to file a support ticket to get that done. And now here we are.

It’s my intent to build out a little site here to help me learn Orchard CMS and maybe tell people a bit about it in the process. I daydream about running a proper tech blog, but I’ve made enough false starts down that road that I won’t kid myself here.

Display Full Post Text on an Orchard Blog Landing Page

I really didn’t like the default behavior of Orchard’s Blog module’s home page. I didn’t want to see the blog’s title, and wanted full posts to display. It looks like there are a bunch of ways you could go about changing this. Here’s what I did, in my custom theme’s Placement.info file:

<Match ContentType="BlogPost">
    <Match DisplayType="Summary">
        <Place Parts_Common_Body_Summary="Content:after;Alternate=Parts_Common_Body"/>
    </Match>
</Match>

This swaps out the Summary of a BlogPost and replaces it with the normal Body.

<Match ContentType="Blog">
    <Match DisplayType="Detail">
        <Place Parts_RoutableTitle="-" Parts_Common_Body_Summary="-" Parts_Common_MetaData="-" />
    </Match>
</Match>

This hides the header stuff on the Blog Detail view.