Update: Please see this newer post. It simplifies this solution drastically, and I don't recommend this version anymore!
I've previously blogged about how to add localization support within ASP.NET MVC before, but that codebase was based on Preview 3, and now that the beta is out there, the code just doesn't work anymore. Period. The concepts I had originally had put out there really don't fly well in the Beta world, or, within the "real" world in which people are using more than just the WebFormViewEngine for their rendering. So, why is there this big disconnect now? Well. it's not so much that global resources fail to work, it's more local resources don't really apply "generally" anymore.
While looking into a solution, and bouncing ideas off of Phil & Brad, I came to the realization that, just like in the Matrix, "There is no spoon" or rather, replace "spoon" with "view location" and you have your reasoning. Now, before you start ranting, let me explain. Yes, there are physical locations at which your views are located, but what if you're ViewEngine was pulling the view's from a database? No guarantee that a "general" solution could achieve local resource support based on a HtmlHelper extensino. However, if you left the local resource delegation up to a ViewEngine, you can now have a concept of a location in relevance to it. (And yes, the point may be moot if you use a different Resource Provider than the asp.net built-in one)
So where does that leave us? Well, we need a general way to access both global and local resources within a View, and global resources within a Controller. Ultimately, the code used to get the resources hasn't changed from my original implementation, however, because we no longer have that concept of a view location, the new implementation delegates this decision correctly to the view engine. Also, before I show the proof of concept, I want to warn you that the guts for my view rendering logic is nearly a copy from what is in the WebFormView source.
So here's the overall design is as follows:
- Any view engine / views can out-of-the-box use "global resources"
- A view engine can decide if it's views can participate in "local resources" by supplying it's own implementation.
- A controller can request "global resources" for messages it's setting within ViewData.
Now, because I wanted to provide a default implementation for the WebFormViewEngine, the implementation isn't nearly as clean as one would like, but it does work great, and falls back to using non-derived ViewPage's and ViewUserControl's when necessary.
View Implementation
We start by deriving ViewPage and ViewUserControl to support localization. These new implementations will add a ResourceHelper, just like Ajax / Html / Url, so that within your view, you can directly access a resource.
1: public class LocalizedViewPage : ViewPage, ILocalizedView
2: {
3: public ResourceHelper Resource { get; set; }
4: }
5:
6: public class LocalizedViewPage<TModel> : ViewPage<TModel>, ILocalizedView
7: where TModel : class
8: {
9: public ResourceHelper Resource { get; set; }
10: }
11:
12: public class LocalizedViewUserControl : ViewUserControl, ILocalizedView
13: {
14: public ResourceHelper Resource { get; set; }
15: }
16:
17: public class LocalizedViewUserControl<TModel> : ViewUserControl<TModel>, ILocalizedView
18: where TModel : class
19: {
20: public ResourceHelper Resource { get; set; }
21: }
The interface ILocalizedView is simply an abstraction I put out so I could determine what type of View I was working with in the View Engine.
Resource Helper Implementation
The resource helper implementation is very straight forward. As previously stated, ResourceHelper is the base that adds support for global resources. The WebFormResourceHelper is what the new web form view engine implementation uses to add support for both global and local resources. As you'll see, WebFormResourceHelper is initialized with the virtual path of the currently rendering view so that it can correctly find the local resource.
1: public static class ResourceExtensions
2: {
3: public static string Resource(this Controller controller,
4: string expression, params object[] args)
5: {
6: ResourceExpressionFields fields = GetResourceFields(expression, "~/");
7: return GetGlobalResource(fields, args);
8: }
9:
10: internal static string GetGlobalResource(ResourceExpressionFields fields, object[] args)
11: {
12: return string.Format((string)HttpContext.GetGlobalResourceObject(
13: fields.ClassKey, fields.ResourceKey,
14: CultureInfo.CurrentUICulture), args);
15: }
16:
17:
18: internal static ResourceExpressionFields GetResourceFields(
19: string expression, string virtualPath)
20: {
21: var context = new ExpressionBuilderContext(virtualPath);
22: var builder = new ResourceExpressionBuilder();
23: return (ResourceExpressionFields)builder.ParseExpression(
24: expression, typeof(string), context);
25: }
26: }
27:
28: public class ResourceHelper
29: {
30: public virtual string GetString(string expression, params object[] args)
31: {
32: ResourceExpressionFields fields = GetResourceFields(expression, "~/");
33: if (string.IsNullOrEmpty(fields.ClassKey))
34: throw new InvalidOperationException(
35: "The resource helper does not support local resources.");
36:
37: return GetGlobalResource(fields, args);
38: }
39:
40: protected string GetGlobalResource(ResourceExpressionFields fields, object[] args)
41: {
42: return ResourceExtensions.GetGlobalResource(fields, args);
43: }
44:
45: protected ResourceExpressionFields GetResourceFields(string expression, string virtualPath)
46: {
47: return ResourceExtensions.GetResourceFields(expression, virtualPath);
48: }
49: }
50:
51: public class WebFormResourceHelper : ResourceHelper
52: {
53: public WebFormResourceHelper(string virtualPath)
54: {
55: VirtualPath = virtualPath;
56: }
57:
58: public string VirtualPath { get; private set; }
59:
60: public override string GetString(string expression, params object[] args)
61: {
62: ResourceExpressionFields fields = GetResourceFields(expression, VirtualPath);
63: if (!string.IsNullOrEmpty(fields.ClassKey))
64: return GetGlobalResource(fields, args);
65:
66: return string.Format((string) HttpContext.GetLocalResourceObject(
67: VirtualPath, fields.ResourceKey,
68: CultureInfo.CurrentUICulture), args);
69: }
70: }
You'll also notice that I've included a controller extension method for extracting global resources. This hasn't changed from the original implementation, but it's straight forward to use.
View Engine Implementation
This is where the rubber meets the road. Since we're now delegating that a ViewEngine can choose to support local resources, the derived view engine implementation is where it supplies it's own ResourceHelper, if it so chooses. In my example, I derive from the WebFormViewEngine and WebFormView, and provide this implementation to supply the WebFormResourceHelper to my localized views. For brevity, and the fact that I didn't write the code for rendering, I'll leave it up to you to see the full implementation for the LocalizedWebFormView in the download. However, the critical portion that you'll see is the following:
1: var localizedPage = page as ILocalizedView;
2: if (localizedPage != null)
3: localizedPage.Resource = new WebFormResourceHelper(ViewPath);
4: page.RenderView(context);
And that's it. In your view, you can now derive from LocalizedViewPage and get access to your global and local resources by doing
1: // global resource
2: <%= Resource.GetString("MvcExample, Welcome") %>
3:
4: // local resource
5: <%= Resource.GetString("Welcome") %>
How does this fit with other View Engines?
View engines need to simply add a reference to the ResourceHelper so that their view's can gain access to it. Obviously, they'll also need to change their ViewEngine to set an appropriate ResourceHelper when instantiating the view, but those view engines can explicitly determine how they would like to treat resources (even completely ignoring Global & Local resources).
And that's it, our View Engine now is completely in control of where my resources come from. They can use the baked-in ASP.NET resource provider, their own logic, or whatever! Again, this implementation is no where near baked, and I strongly urge you to look at your solution to see how this would fit in, and (obviously) make the code "production worthy". I'm hoping that some of these concepts make it into future MVC releases. You can also download the source for these files here. Enjoy!
Currently rated 4.0 by 3 people
- Currently 4/5 Stars.
- 1
- 2
- 3
- 4
- 5