You still have to assign them into code somehow and ensure that the names match properly. But I honestly don't see any big advantages to that except that all literals are all in one place. I suppose there could be other ways to tackle this such as pre-generating all the strings into an object on the client and then using the object (like Res.NoResourcesAvailable) to get the resource. The easiest approach however would be if strongly typed resources worked properly in ASP.NET, but I don’t have time at the moment to build that out. ResC adds outer quotes and escapes any quotes inside of the string JSON style. With string expressions in script code look like this:įunction GetResourceStrings_Callback(Resources) / Encodes a string to be represented as a string literal String Value = Res(ResourceKey, "westwindglobalization" ) / This simplifies adding values to client script with code like this: / Creates a client side compatible string including the quote characters. Return Res(ResourceKey, "westwindglobalization" ) / Defaults resource set and requires only the ResourceId / Global Resource Helper function for easier access. GetGlobalResourceObject(ResourceSet, ResourceKey) as string Public string Res( string ResourceKey, string ResourceSet) / Global Resource Help Function for easier syntax Sooo… to make things a little easier in client code (both markup and script) I think it’s probably a good idea to create a few helper functions with shorter names and simpler syntax. In any case typically I prefer to have explicit resource strings stored in global resources where they can hopefully be reused more frequently.īut there’s another problem with the syntax of both entries above: Both will fail if the string returned includes a single quote as the output is generated as a literal string as well as any escaped characters that can potentially be misinterpreted by the client script parser if the literal is placed inside of JavaScript code. VS.NET generated a Resource key but for some reason the Implicit key is never fired at runtime. Well, it’s supposed to work, but unfortunately I can’t get the resource key to work either inside of script or just in the middle of the page proper. The advantage of the latter is that you can assign a meta:resourcekey to the ASP.NET 2.0 Localize control: For example in script code where it gets kinda ugly: I know some folks shutter at using expressions, but if you have literal text in certain places you can’t easily get around using these expressions. You can also get this stuff into the markup using classic ASP style expressions: GetGlobalResourceObject("westwindglobalization","NoReourcesFound") as string Behind the scenes ASP.NET has hooked up the appropriate ResourceProvider and is asking it to return to you the appropriate ResourceKey. These two functions allow you to get a provider specific resource without having to muck with resource managers. So, ASP.NET Pages make it pretty easy to get localized ‘objects’ back using Control.GetLocalResourceObject() and Control.GetGlobalResourceObject(). This is made even worse by the fact that the entire admin interface is driven mostly through AJAX code so a lot of strings are embedded on the client side in script code. The first thing I ran into is that by far the hardest part of the localization process is not the UI control assignments, but any text assignments in code. So the first task is to actually localize (or rather make localization ready) the various admin forms and helpers for the Localization provider. Took a while to get everything working correctly and get the live resource editing hooked up and little kinks worked out. I’m finally to the point where I can start using my localization provider code to actually localize a few applications and pages.
0 Comments
Leave a Reply. |