I would suggest your second option: creating a subclass of NVLB to add the language property.
However, I would also suggest that .NET has a partial answer for you in the form of Culture. On the Thread object you'll find a couple culture properties, and most code keys off the UICulture for this sort of thing.
The data portal even carries the client-side culture values over to the server (look at Chapter 4 and the discussion of ApplicationContext), so you get consistent access to the user's culture even on the application server.
If you can use the built-in culture value, perhaps you don't need a custom NVLB at all, but rather can just have your DataPortal_Fetch() rely on this standard value.
RockfordLhotka:
...
However, I would also suggest that .NET has a partial answer for you in the form of Culture. On the Thread object you'll find a couple culture properties, and most code keys off the UICulture for this sort of thing.
...
If you can use the built-in culture value, perhaps you don't need a custom NVLB at all, but rather can just have your DataPortal_Fetch() rely on this standard value.
No problem, use what works ![Smile [:)]](/emoticons/emotion-1.gif)
But to be clear, the thread culture settings are for locationalization - that's why they are in .NET in the first place. The culture specifies the language in use on the client workstation, which is typically the language the user wants to see. .NET automatically uses this culture setting to pull resources based on that culture (CSLA .NET uses this to localize all its string values for instance).
However, you can get the language value (such as en for english, ru for russian, etc.) from the culture object as well. Your code can then use that language value to tailor its data queries.
Of course I could be totally misunderstanding your problem - but if all you need to do is pass a language value (such as en, es, ro, it and so forth) to the server so your data portal code can do the right queries per-language, then culture already does this for you.
On the other hand, if your database includes the customer's language choice and you are tailoring the data queries based on that customer data value, then I don't see why you'd pass it via criteria at all. The value is already in the database after all, so it doesn't (to me anyway) make sense to pull it back to the client just to send it to the server again.
....as a relative noob to programming, how would you go about subclassing the NVLB or more particularly its Criteria class?
I did it this way:
//Factory Method
private static Hashtable _list;
public static AddressTypeList GetAll()
{
if (_list == null)
{ //initial load, just get the default culture list
_list = new Hashtable();
_list[Thread.CurrentThread.CurrentCulture.Name] = DataPortal.Fetch<AddressTypeList>();
}
else if (_list[Thread.CurrentThread.CurrentCulture.Name] == null)
{ //need to load the list for this culture
_list[Thread.CurrentThread.CurrentCulture.Name] = DataPortal.Fetch<AddressTypeList>();
}
return (AddressTypeList)_list[Thread.CurrentThread.CurrentCulture.Name];
}
And in my Fetch, I have:
do
{
this.Add(new NameValuePair(reader.GetInt32("AddressTypeId"), ResourceHelper.GetResource(reader.GetString("AddressTypeCd"), ResourceFiles.Lookups, true)));
} while (reader.Read());
In my database, I have 'AddressType_Home', 'AddressType_Work', etc. which matches key/values in my resource files.
Copyright (c) Marimer LLC