Localizing values within a DropDownList

On October 4, 2005, in Uncategorized, by derekgreer

For today’s post I’ve decided to discuss localizing values within an HTML dropdown list. Populating a list with localized values can be relatively easy since running the “Generate Local Resource” from the VS2005 menu will set up implicit localization for you. The shortcoming of this method is that it doesn’t allow you to vary the items in the list based upon the locale. In some cases there may be a business need to not only localize the values within the list, but also to vary the list depending on the current locale/culture. Using implicit and explicit localization doesn’t handle this scenario since this form of localization depends on the keys being staticly defined. Of course you can always look to database solutions, but this will typically be too much overhead for localization concerns and doesn’t afford the flexibility resource files allow. To load varying lists into a dropdown based upon the current locale, you can use the ResourceManager class within the System.Resources namespace. ResourceManager allows you to load values from satellite assemblies or from a resources file. For demonstration purposes I will be discussing the latter.

To begin, create an Assembly resource file such as Country.resx within Visual Studio and added some name value pairs. Once this file is created, use the resgen.exe Visual Studio command line tool to compile this into a resource file named Country.resources. You may then call ResourceManager’s static CreateFileBasedResourceManager() method from within the code behind of your ASP.Net page or user control to load up the resources contained within Country.resources. Once you have a reference to the newly created ResourceManager, you may then bind your DropDownList control to a ResourceSet obtained by calling GetResourceSet() on your ResourceManager instance. Alternately you could iterate over the resources within the obtained ResourceSet. The following snippet demonstrates this technique:

protected override void OnPreRender(EventArgs e)
ResourceManager rm = ResourceManager.CreateFileBasedResourceManager("Country",
Server.MapPath("~/Resources") + Path.DirectorySeparatorChar, null);

ResourceSet rs = rm.GetResourceSet(CultureInfo.CurrentCulture, false, true);

CountryList.DataSource = rs;
CountryList.DataTextField = "Value";
CountryList.DataValueField = "Key";

Ultimately you may wish to use a similar method for obtaining resources from a satellite assembly to enable XCOPY deployment of your resources. Happy localizing!


The Microsoft Provider Model

On October 2, 2005, in Uncategorized, by derekgreer

For my first post of substance I thought I’d write about the new Microsoft Provider Model used within the .Net 2.0 framework. The Provider Model is a new construct for addressing extensibility within the .Net framework. I define the Provider Model as being three things: a pattern, a framework API, and a specification.

The Provider Model Pattern
The Provider Model is a pattern in the sense that it is a formalized blending and composition of existing patterns producing a unique construct for addressing extensibility.

The Provider Model Framework API
The Provider Model is a framework API in that the 2.0 .Net framework provides several abstract base classes for creating providers and provider-backed objects.

The Provider Model Specification
The Provider Model can be considered a specification because in addition to the base classes provided and the patterns composed, Microsoft provides an implementation specification for how providers are to be designed and how configuration should be handled.

The Provider Model is a construct which abstracts the facilitating implementation for some portion of functionality from the defining class. There are two parts to the use of the Provider Model: 1) The provider-backed class and 2) The provider itself. The provider-backed class is the portion of functionality which defines the features which a provider will implement. This class defines public static methods which proxy calls to a default provider. By convention, the class also exposes the default provider along with the collection of all additional configured providers for the class. This allows the consuming application to provide a list of available providers and call a specific provider if desired. Some examples of provider-backed classes within ASP.Net are the Membership and Roles classes. The provider is the implementation of the functionality defined by the provider-backed class. For the Membership class, Microsoft provides an SqlMembershipProvider which implements the Membership functionality based upon the use of a Microsoft SQL database. Other Membership providers might include an AccessMembershipProvider, a SybaseMembershipProvider, or an XmlMembershipProvider.

Aside from the extensibility the Provider Model achieves for some of the new ASP.Net features, probably the biggest benefit to be gained from the provider model is the standardization this construct provides for achieving extensibility concerns. The use of standard design patterns can achieve the same results, but after learning how one provider and provider-backed class is used and configured you will be familiar with all the other Provider Model based functionality within the .Net framework as well as any Provider Model based functionality following the Microsoft specifications.

For more information on the Provider Model, see Rob Howard’s article: Provider Model Design Pattern and Specification, Part 1.