Localizing jQuery plugins

I’ve spent some time to figure out how to localize my jQuery plugins and I’ve just found out a way that works just fine. Disclaimer: I’m not 100% sure of how namespacing works in jQuery so this might not be the correct way.

I’m using the meta header accept-language to control which language to use. It allows me to select the language in my backend (using user settings or whatever) instead of just using the languages defined by the browser. An ASP.NET MVC3 header would look like this in the layout:

<meta name="accept-language" content="@System.Globalization.CultureInfo.CurrentCulture.Name" />

You should be able to do the same thing in PHP or whatever language you use.

Next thing to do is to add the localization structure to your plugin script file:

(function($) {
    $.yourPluginName = {
        texts: {
            title: 'Please wait, loading..'
        translations: []
    var methods = {
		// your methods here.

    $.fn.yourPluginName = function(method) {

        if (methods[method]) {
            return methods[method].apply(this, Array.prototype.slice.call(arguments, 1));
        } else if (typeof method === 'object' || !method) {
            return methods.init.apply(this, arguments);
        } else {
            $.error('Method ' + method + ' does not exist on jQuery.yourPluginName');



That will make the plugin work if no languages are loaded. The translations will be loaded into the $.yourPluginName.translations array by another script.

We got one thing left to do before we can use the texts in your script. We need to load the correct language. Create another script called jquery.yourpluginnamne.localization.js and load it after$.yourPluginName.texts.anyTextName in your plugin to use the localized strings.

Get an unique session in each browser tab

I got a lot to do at work, hence the silence. I got a lot to blog about, but so little time ;/ I found an interesting question at stackoverflow which this answer is for (also to show you that the blog is not forgotten).

A user wanted to store browser tab specific data which can be a problem since most browsers shares a session between different tabs. The solution is to create a new route which generates a GUID and then
use that guid to fetch and store session information. Keep in mind that you need to routes: One that works for users which just surfed into the site, and one that loads an existing guid.

Here is the route class:

public class GuidRoute : Route
	private readonly bool _isGuidRoute;

	public GuidRoute(string uri, object defaults)
		: base(uri, new RouteValueDictionary(defaults), new MvcRouteHandler())
		_isGuidRoute = uri.Contains("guid");

		DataTokens = new RouteValueDictionary();

	public override RouteData GetRouteData(HttpContextBase httpContext)
		var routeData = base.GetRouteData(httpContext);
		if (routeData == null)
			return null;

		if (!routeData.Values.ContainsKey("guid") || routeData.Values["guid"].ToString() == "")
			routeData.Values["guid"] = Guid.NewGuid().ToString("N");

		return routeData;

	public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
		return !_isGuidRoute ? null : base.GetVirtualPath(requestContext, values);

Replace the default route in global.asax with it:

	"Default", // Route name
	"{controller}/{action}/{id}", // URL with parameters
	new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

routes.Add("Default", new GuidRoute(
	new { controller = "Home", action = "Index", guid = "", id = UrlParameter.Optional }));

routes.Add("GuidRoute", new GuidRoute(
	new { controller = "Home", action = "Index", guid = "", id = UrlParameter.Optional }));

And finally some extension methods to make life easier in the controllers:

public static class ControllerExtensionMethods
	public static string GetGuid(this Controller controller)
		return controller.RouteData.Values["guid"].ToString();

	public static void SetGuidSession(this Controller controller, string name, object value)
		controller.Session[controller.GetGuid() + "_" + name] = value;

	public static object GetGuidSession(this Controller controller, string name)
		return controller.Session[controller.GetGuid() + "_" + name];

One thing left though: Any browser bookmarks will use an old GUID. Should not be a problem in most cases (unless the user opens the bookmark in multiple tabs = sharing the session between the tabs). Same
thing goes for opening a link in a new tab = shared.

Introducing my logging library

I’ve just published the first version (consider it a beta) of my logging library to the official nuget server(s).

Why another library when there are existing ones as log4net and nlog? Because it should be easier to get started and you should still have the power to customize the logging if needed. Griffin.Logging do not have a configuration file, everything is configured through code.

Simple syntax

The easiest approach only requires one line to configure the framework:


You can swap the AddFile method to AddConsole if you would like.

Fluent syntax

Use the fluent syntax if you need more power:

var config = new FluentConfiguration()
	  .As.ConsoleLogger().Filter.OnLogLevelBetween(LogLevel.Info, LogLevel.Error)


public class MyClass
    ILogger logger = LogManager.GetLogger<MyClass>();

    public MyClass()
        // Built in formatting for cleaner syntax.
        logger.Info("Welcome {0}!.", user.Name);
    public void HideError()
            throw new InvalidOperationException("No no", new OutOfScopeException("Can't thing anymore"));
        catch (Exception err)
            // Log an exception. The inner exceptions are logged too (recursive)
            logger.Warning("Ooops, we got an exception.", ex);



Check the homepage for more information or just install the nuget package “griffin.logging“.

First draft of my alternative HTML helpers

I’m getting closer to a first release of my ASP.NET MVC contribution project called Griffin.MvcContrib. I’ve just committed my first draft of the alternative HTML helpers. I’ve focused on helpers for Form tags in this commit. If you are wondering what’s wrong with the original helpers, please see my previous blog entry about using extension as an important part of a framework.

Here are some new features that my HTML providers add:


By using extension methods there is no way to extend the functionality in them. I’ve solved this in two ways. First and foremost there aren’t any extension methods. My HtmlHelper class is just a facade that tries to use the DependencyResolver to find the proper generators. It will also create the default implementations if no extended ones are found.

To extend one of the helpers, simply derive it and make the changes you like. The following sample with add a “title” attribute to all text areas (which then can be picked up by a jquery script to create a nice tool tip)

    public class MyCustomTextAreaGenerator : TextAreaGenerator
        public MyCustomTextAreaGenerator(ViewContext viewContext) : base(viewContext)

        protected override IEnumerable<NestedTagBuilder> GenerateTags()
            var generatedTags = base.GenerateTags().ToArray();
            generatedTags[0].MergeAttribute("title", "You are so dirty!");
            return generatedTags;

and then register it in your current inversion of control container. Here is a sample for autofac:


The following generators do currently exist:

  • CheckBoxGenerator
  • RadioButtonGenerator
  • SelectGenerator
  • TextAreaGenerator
  • TextBoxGenerator

Post processing generated HTML tags

You can also add more generic adapters which can be used to transform the generated HTML tags. The sample project which is included in github shows you how to:

  • create watermarks for textboxes
  • Add tooltips
  • Transform all age fields into UI sliders

Here is the watermark example:

    public class WatermarkAdapter : IFormItemAdapter
        public void Process(FormItemAdapterContext context)
            // there is a "Watermark" metadata but it cannot currently be set.
            // unless you are using a custom metadata provider like the one in the localization demo.
            if (string.IsNullOrEmpty(context.Metadata.Description) || !context.TagBuilder.Attributes.ContainsKey("class") || !context.TagBuilder.Attributes["class"].Contains("watermark"))

            context.TagBuilder.MergeAttribute("title", "Watermark:" + context.Metadata.Description);

And the jquery script creating the actual watermark (uses the jquery watermark plugin):

function watermark() {
    $('[title*="Watermark:"]').each(function () {

Enum galore

Are you using enums? Sure you do. The html helpers in Griffin.MvcContrib can generate lists, checkboxes and radio buttons automatically for them.

The following code:

@Html2.CheckBoxesFor(model => model.InputType) <br />
@Html2.RadioButtonsFor(model => model.InputType) <br />
@Html2.DropdownFor(model => model.InputType) <br />

Generates the following HTML:

HTML generated by enum html helpers

Lets format that dropdown

Dropdowns are something else that I’ve tried to improve. You can use formatters to determine how the select lists should be generated.

The following example are using a custom formatter which has been made to transform user objects:

@Html2.DropdownFor(model => model.CurrentUser, Select.From<UserFormatter>(Model.Users))

And the actual formatter:

    public class UserFormatter : ISelectItemFormatter
        public SelectListItem Generate(object itm)
            var item = (User)itm;
            return new SelectListItem
                Text = string.Format("{0} {1}", item.FirstName, item.LastName),
                Value = item.Id.ToString()

There are to formatters built into MvcContrib:

  • IdTitle
  • IdName

They uses reflection to find the proper properties.


All mentioned helpers should work without any problems. But I’m not done with the helpers yet. This post is most about me wanting feedback. Have I made any stupid mistakes? Do you have any suggestions how I can improve the code?

Please take a look at the sample project

The actual source code for all helpers can be found here

A more structured MembershipProvider.

If you take a look at the official documentation that tells you how to create your own custom MembershipProvider you’ll notice that the documentation is mostly about describing:

  • how you should throw exceptions and when
  • Which events you should invoke and when
  • How the logic in each method should work.

Let’s stop here for a moment. What are the most typical reason for creating a custom membership provider? Is it to change the behaviour(/contract) of the provider? Or maybe change the password handling? No. The most common reason is to add support for a custom data source.

Back to the MembershipProvider class. As I see it, it has four responsibilites:

  1. Be able to handle all members (login, register etc)
  2. Load/Store information from/in a data source
  3. Keep track of account/password policies and handle those.
  4. Handle passwords (encrypt/hash/compare)

And that’s why it’s such a tedious task to create a custom MembershipProvider: You need to implement all of those responsibilities.

Griffin.MvcContrib to the rescue!

With the MembershipProvider in Griffin.MvcContrib you do not need to know all of those details. Our MembershipProvider uses DependencyResolver (a built in
Service Locator in MVC3) to lookup the dependencies that it needs. You need to register the following services in your inversion of control container:


Used to retrieve/store membership accounts from/to a data source. It’s the only thing you need to implement to get support for a custom data source (like a database or a web service).

Source code


Used to handle passwords (comparing them, encrypting, decrypting). There are three strategies available in the framework:

  • ClearTextStrategy – Store passwords as clear text in the database
  • HashedPasswordStrategy – Hash passwords before they are stored.
  • TripleDesPasswordStrategy – Use TripleDes to encrypt/decrypt passwords.

Source code


Defines how passwords should be treated. For instance the minimum length, number of attempts before locking the account etc.

Two policy implementations exist. One who loads the policies from web.config and one “normal” class which you can create and assign the properties in.

Source code

How to use it

Disclaimer: You should know that Account Administration Tools won’t work since the provider has a dependency on DependencyResolver. Other than that, the provider works like any other provider.

Start by modifying your web.config to specify the new provider:

    <membership defaultProvider="GriffinMembershipProvider">
        <clear />
        <add name="GriffinMembershipProvider" type="Griffin.MvcContrib.Providers.Membership.MembershipProvider" applicationName="/" />

Then you need to register the dependencies in your inversion of control container. Here is a sample for Autofac:

protected void Application_Start()
	ContainerBuilder builder = new ContainerBuilder();
	builder.RegisterInstance(new PasswordPolicy
			 IsPasswordQuestionRequired = false,
			 IsPasswordResetEnabled = true,
			 IsPasswordRetrievalEnabled = false,
			 MaxInvalidPasswordAttempts = 5,
			 MinRequiredNonAlphanumericCharacters = 0,
			 PasswordAttemptWindow = 10,
			 PasswordMinimumLength = 6,
			 PasswordStrengthRegularExpression = null
	// the rest of the initialization

If you like to switch from hashed passwords to encrypted passwords you just need to register TripleDesStrategy in the container instead. Or implement your own strategy.


The code is available at github and can be installed using nuget install-package griffin.mvccontrib.

Why extension methods should not be used as part of a framework.

Two of my favorite frameworks/libraries uses extension methods heavily. Autofac uses extension methods during registration and ASP.NET MVC3 for their HTML Helpers. Since extension methods are static, they are closed for extension. Which are one of the most important principles for object oriented programming.

For MVC I would like to be able to add a tooltip automatically for all editors and labels. It’s really simple, I just want to add a “title” attribute to all generated HTML elements where the ModelMetadata contains a “Description”. The source code for LabelFor looks like this:

    public static class LabelExtensions {
        public static MvcHtmlString Label(this HtmlHelper html, string expression) {
            return LabelHelper(html,
                               ModelMetadata.FromStringExpression(expression, html.ViewData),

        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures", Justification = "This is an appropriate nesting of generic types")]
        public static MvcHtmlString LabelFor<TModel, TValue>(this HtmlHelper<TModel> html, Expression<Func<TModel, TValue>> expression) {
            return LabelHelper(html, 
                               ModelMetadata.FromLambdaExpression(expression, html.ViewData), 

        public static MvcHtmlString LabelForModel(this HtmlHelper html) {
            return LabelHelper(html, html.ViewData.ModelMetadata, String.Empty);

        internal static MvcHtmlString LabelHelper(HtmlHelper html, ModelMetadata metadata, string htmlFieldName) {
            string labelText = metadata.DisplayName ?? metadata.PropertyName ?? htmlFieldName.Split('.').Last();
            if (String.IsNullOrEmpty(labelText)) {
                return MvcHtmlString.Empty;

            TagBuilder tag = new TagBuilder("label");
            tag.Attributes.Add("for", html.ViewContext.ViewData.TemplateInfo.GetFullHtmlFieldId(htmlFieldName));
            return tag.ToMvcHtmlString(TagRenderMode.Normal);

Hence it’s impossible to do anything about the helper. I do understand why they use extension methods. It’s great since it’s very easy to find all available helpers. The problem is that you can’t do anything do modify the data that they generate.

The solution

Convert all extension methods to facades for the real implementation, and use DependencyResolver in the extension methods to find the proper classes. Create some interfaces and default implementations for all generators.

The new LabelHelper:

internal static MvcHtmlString LabelHelper(HtmlHelper html, ModelMetadata metadata, string htmlFieldName)

    var labelGenerator = DependencyResolver.Resolve<ILabelGenerator>();
    return labelGenerator.Create(html, metadata, htmlFieldName);

The default implementation (simplified example):

	public class LabelGenerator : ILabelGenerator
		public virtual void Create(HtmlHelper html, ModelMetadata metadata, string htmlFieldName)
            string labelText = metadata.DisplayName ?? metadata.PropertyName ?? htmlFieldName.Split('.').Last();
            if (String.IsNullOrEmpty(labelText)) {
                return MvcHtmlString.Empty;

            TagBuilder tag = new TagBuilder("label");
            tag.Attributes.Add("for", html.ViewContext.ViewData.TemplateInfo.GetFullHtmlFieldId(htmlFieldName));
            return tag.ToMvcHtmlString(TagRenderMode.Normal);
		protected virtual void ProcessTag(TagBuilder tag, ModelMetaData metaData)

Which would allow me to create the following implementation:

	public class LabelWithTitlesGenerator : LabelGenerator
		protected override void ProcessTag(TagBuilder tag, ModelMetaData metaData)
			if (metaData.Description != null)
				tag.Attributes.Add("title", metaData.Description);

The only thing left is to inject it in my container and create a small jquery script which creates the actual tooltip using the “title” attribute.


Extension methods are closed for extension. Once declared you can not do anything to extend the functionality that they provide. It’s the same as if you would develop a framework where you put sealed on all your classes.

Extension methods were created to be able to make life easier by proving convenience methods for existing classes. The intention was not that you should use them as a part of your framework since you close down that part for extension if you do. The extension methods become locking out methods ;O

Easy model and validation localization in ASP.NET MVC3

Update I’ve written a more complete article about the framework at codeproject.com.

If you have googled a bit you’ll read that you should use DescriptionAttribute and DisplayNameAttribute to get localization which will result in a view model that looks something like this:

    public class UserViewModel
        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserId", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserIdDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public int Id { get; set; }

        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserFirstName", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserFirstNameDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public string FirstName { get; set; }

        [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDisplayName(ErrorMessageResourceName = "UserLastName", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        [LocalizedDescription(ErrorMessageResourceName = "UserLastNameDescription", ErrorMessageResourceType = typeof(Resources.LocalizedStrings))]
        public string LastName { get; set; }

Don’t do that.

The solution to get cleaner DataAnnotation localization is to derive the attributes and do some magic in the derived classes. The problem with that solution is that client-side validation stops working unless you create new adapters for your derived attributes.

Don’t do that.

The easy solution

I found an excellent post by Brad Wilson that goes through most of the new stuff in MVC3. It’s a must read. When reading it I came up with the idea to use the new Meta Data providers to do the localization. The solution works quite well and you’re models become clean again:

    public class UserViewModel
        public int Id { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }

You need to specify the new providers (created by me) in your global.asax:

        protected void Application_Start()
            var stringProvider = new ResourceStringProvider(Resources.LocalizedStrings.ResourceManager);
            ModelMetadataProviders.Current = new LocalizedModelMetadataProvider(stringProvider);
            ModelValidatorProviders.Providers.Add(new LocalizedModelValidatorProvider(stringProvider));

That’s it. No more messy attributes.

Defining the localization resources

I created an interface called ILocalizedStringProvider which is used by both providers. This means that you do not have to use String Tables. Just create a new class and implement that interface to get support for your database, XML file or whatever you choose.

In my example I used a string table and the strings in it looks like this:

As you see, you should name your strings as “ModelName_PropertyName” and “ModelName_PropertyName_MetadataName” to include meta data like Watermark and NullDisplayText. Refer to MSDN to see which kind of meta data there is.

As for validation attributes, the string table names should simply be the attribute name without the “Attribute” suffix.

Code and documentation

The code is available at github.
Documentation is available here.


Comments are now closed. Either open tickets at github or ask questions at stackoverflow.com with the tag “griffin.mvccontrib”. Write a comment starting with “@jgauffin” if I don’t answer within reasonable time ;)

Getting information into the Layout without using ViewBag.

You should avoid using the ViewBag as much as possible since you get run-time errors instead of compile time error if something fails. The problem is that it can be hard to avoid it if you are using information in your layout.

The solution that I’m using lets you do the following:

public class YourController : BaseController
    public ActionResult YourAction()
        LayoutModel.MetaDescription = "Does something in the application";
        return View();

And in your _Layout.cshtml:

<meta name="description" value="@LayoutModel.MetaDescription" />

See? Everything is typed.

The approach I’m using is to create a base class for views and inherit WebViewPage in it. First things first, add a model for your layout:

public class LayoutViewModel
    public string MetaKeywords { get; set; }

Then add the following to your BaseController:

public class BaseController : Controller
    private LayoutViewModel _layoutModel = new LayoutViewModel();

    public LayoutViewModel LayoutModel { get { return _layoutModel; } }

    protected override void OnResultExecuting(ResultExecutingContext ctx) 
        var viewResult = ctx.Result as ViewResult;
        if (viewResult != null)
            viewResult.ViewBag.LayoutModel = LayoutModel;


Ok. I know. I’m cheating and using the ViewBag. But since it’s only in one place it’s less error prone than using the viewbag everywhere.

Now create the View base class. You need to create two versions to have support for typed views.

public abstract class ViewBaseWithLayoutModel : WebViewPage
    public LayoutViewModel LayoutModel { get { return (LayoutViewModel)ViewBag.LayoutModel; } }
public abstract class ViewBaseWithLayoutModel<T> : WebViewPage<T>
    public LayoutViewModel LayoutModel { get { return (LayoutViewModel)ViewBag.LayoutModel; } }

The last thing is to specify your new base view class in your ViewsWeb.config:

    <pages pageBaseType="Namespace.To.ViewBaseWithLayoutModel">

That’s it.

Begin/End asynchronous methods vs the new Async methods

A new asynchronous model was introduced in .NET 3.5sp1 where all methods ends with ‘Async’ like Socket.RecieveAsync. I will not give you any code samples, there are several articles out there which shows how the new model work. Instead I’m going to try help you understand the differences and to select which model you should use for your project.

The benefit with the new model is that it’s a lot more similar to the I/O Completion Ports threading model which exists in Windows (and is used internally for all asynchronous operations in .NET). The idea is that the IO model should create as few objects as possible per operation, compared to the old model where one IAsyncResult object is created per operation.

I haven’t looked at the code (using reflector) for the old model versus the new one, but I bet that the code for the new model is a lot more efficient than the old one since it’s more similar to IOCP.

Which method should you choose then?

Choose the one that you are most comfortable with (which probably is Begin/End since it’s the model that have existed since day one). It’s more likely that you loose performance instead of gaining
if you pick a model that you do not fully understand.

As always: Never optimize something unless it have been proven to be a problem.