SpeakENG

Previously I mentioned that we switched to MonoRail for all of our new features. Well, MonoRail doesn't make page localization any easier than Web Forms does.  As a matter of fact, it actually breaks an important part of ASP.NET's localization (something I should probably submit a patch for, heh).  Basically, the DefaultResourceFactory in MonoRail creates IResources that wrap ResourceSets, which will not resolve resources to their parent resource. In other words, if you have Res.ko-KR.resx which defines String1 and Res.resx which defines String1 and String2, then calling GetString on a ResourceSet when your locale is ko-KR with String1 will work, but String2 will fail.  Calling GetString with any other locale, will return the String2 from Res.resx. To get around this, we created an IResourceFactory that returns IResources that wrap ResourceManagers instead of ResourceSets, which are capable of properly traversing the resource tree.  I'll probably submit this code soon. 

Anyways, in order to localize with MonoRail, you still need to create your resx file, add an attribute to your controller to map that resx file to something in your view's property bag, and create, name and initialize each string in your resx file.   

What we did was create a new generator like the one mentioned in my previous post that converts mybrail files to brail files.  All it does is convert this: 

${g.Test: Global Text} <br />
${v.ViewTest: View Text} <br />
${c.ControllerTest: Controller Text} <br />

To this: 

${g.Test} <br />
${c.Localization_ViewTest} <br />
${c.ControllerTest} <br /> 

Now a few things happened here:

1. A file called Global.resx was created.
2. A file called Test.resx was created (Test is the name of the controller)
3. A resource called Test was added to Global.resx and initialized with the value "Global Text"
4. A resource called ControllerTest was added to the Test.resx and initialized with the value "Controller Text"
5. A resource called Localization_ViewTest (Localization is the name of the view) was added to Test.resx and initialized with the value "View Text"
6. v.ViewTest was converted to c.Localization_ViewTest

Essentially, what you end up with, is one resx for your global strings, and one resx per controller, with view specific strings being stored in the controller resx with ViewName_ prefixed to them.  There's still one piece missing to the puzzle, which is how do the views know what g and c are? Do we attribute each controller with a g resource and a c resource? No... that would be too much work for us. Instead what we do is define a new IControllerDescriptorProvider that wraps a DefaultControllerDescriptorProvider and adds appropriate ResourceDescriptors to the Resources collection of the descriptor built by the DefaultControllerDescriptorProvider.   

There is some room for improvement, like gracefully handling the case where you define and give a value for a resource twice in the same file or two seperate files, e.g. ${g.Test: Hi} ${g.Test: Hello}.  In this case, g.Test will be Hello.  In the case where they're in seperate files, it'll depend on which one was saved last (ew).  A decent way around this would be to detect this happening and pop a message box if you try to do this.

Hi, I am Khalil
as part of Aaron's team, I want to write a small introduction. I am the "Youngest" yet i am the oldest. I joined the Eleutian team in september 2006 (that'll explain the youngest part), and am married with two kids and as I am told right now another one is on the way! (man, I feel old)  I am a recent graduate who worked for about 7 months in a telephony company and then decided that it is time to embark on different journey called Eleutian. I guess that is about it for now. let's see what is going to happen.

One of the things we love to do is remove tedium from code. That subject will probably be the topic of this post, and many of our posts in the future I'm sure, as we've done a lot of things in that department.  ASP.NET is lacking in a number of areas, as I'm sure most of you know.  It's "strong point" is supposed to be its declarative nature--but that often leads to very difficult to test pages.  Not only that, but it's declarative syntax leaves much to be desired.  My primary complaint is with its verbosity.  There's nothing simple about ASP.NET syntax.  Here's an example:

<asp:HyperLink runat="server" ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text='<%$ Resources: PageStrings, Login_lnkForgot_Text %>' />

Now, let's complain a little.  First, we've got that runat="server" tag.  Who's idea was that?  I mean, I understand why it's there, but how often are you going to want <asp:Anything> to be sent to the client in that form?  Wouldn't it make more sense to just ASSUME that <anything:Anything> was runat="server" and just allow us to specify runat="client" and strip that attribute when rendering if we really want to send that to the client?

Next, we've got the ID tag.  I don't really have a problem with that, it's implemented just fine.  Then there's the NavigateUrl.  Notice the ~.  I love that.  It's something that ASP.NET did right. It makes it a breeze to make pages location agnostic... unless of course you want to use a non-asp control.  Then you've got to use this lovely syntax:

<img src='<%= ResolveClientUrl("~/Images/img.gif") %>' />

Ah yes, that just screams beautiful.  Now would it have really been that difficult to replace ~ with ApplicationPath and let ~~ by as ~ in attributes? 

OK, let's move on to my favorite subject--Globalization/Localization.  ASP.NET 2.0 has come a long way on this front.  It's much easier to localize your pages the way ASP.NET 2.0 wants you to than the way ASP.NET 1.0 wanted you to, especially with the new meta:resourcekey attribute and automatic generation of resources.  Unfortunately, it's still not as simple and elegant as it could be.  If you don't want to use the meta:resource attribute (because you have a shared string) then you have to use the lovely Resources: syntax seen up above, and you have to manually create your resx file, and manually name and fill in your default locale value.  If you want to localize a literal, you get to use wonderfully verbose <asp:Localize> control. 

Another complaint that isn't demonstrated in the example is with Databinding.  The databinding syntax is pretty clean, I don't have any complaints about that, but its implementation is a bit poor, mainly because of its use of uncached reflection.  It's been a while since I benchmarked it, but if my memory serves me (and often it doesn't) then it took about 30% longer to databind using the reflexive <%# Field %> syntax than it did to use <%# ((Class)Container.DataItem).Field %>.  Who wants to write all of the latter, especially with autocomplete in aspx pages being flaky at best?

So how could ASP.NET be less verbose and more elegant? How could WE make it better without being able to extend the many internal and sealed classes that make up the webforms engine?

Preprocessing!

Here's an overview of what you do.

1. Create a generator that extends Microsoft.CustomTool.BaseCodeGeneratorWithSite for .aspx files and do your preprocessing here.
   
2. Create a wizard that extends Microsoft.VisualStudio.TemplateWizard.IWizard to set up a file hiearchy like this:
   • Page.myaspx
     • Page.aspx
       • Page.aspx.cs
       • Page.aspx.designer.cs
3. Create an ItemTemplate for your item that contains these files and sets your custom tool to the generator you created in step one.
4. Add a new myaspx to your project and make sure you don't ever modify the aspx directly (this takes some getting used to)

So what are some things you could filter/generate/preprocess?

• Add runat="server" tags to all <anything:anything> nodes that don't have it.
• Replace "~/blah" with an appropriate call to ResolveClientUrl
• Do some localization magic

<asp:HyperLink ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text="$:Forgot your Username or Password?" />

          This is actually the markup that we wrote to generate the markup at the beginning of this post.  See the $:?  That tells the generator to create a resource in PageStrings.resx with the format Page_ID_Property that has the value that appears after the $:.  You never need to touch that resx file.  You can just write your markup, define your strings, and not be interrupted, or even have to name your strings.  If you want to name your strings, say something global.  Just do "$Name: This is a string" and if you want to use it later just use "$Name".

• Make databinding strongly typed.  This requires a bit of help, as you can't easily infer the type being bound by just inspecting the source.  Our solution was to add a DataType="Class" attribute to whatever the repeating control was.  For example:

  
  <asp:Repeater ID="repeater" DataType="BoundClass">
    <ItemTemplate>
      <asp:Label ID="textBox" Text='<%#@Name%>' />
    </ItemTemplate>
  </asp:Repeater>

Notice the @ in the <%#%> tag.  That gets replaced with ((BoundClass)Container.DataItem), so you can do things like <%# String.Format("{0} {1}", @FirstName, @LastName) %>

So that's how we made ASP.NET more manageable.  Now, there are still several issues with ASP.NET WebForms that caused us to eventually switch to MonoRail, which also benefits from preprocessing, but I'll post on that later.

Aaron said I should post an introduction or something on his blog. I've been with Eleutian for a little less than Aaron. I am one of the developers that he "leads" and recently moved to Seattle to work full time. Before Eleutian, I worked at the University of California Riverside as a Systems Programmer/Administrator for the Computer Science department. Like Aaron, I intend to see what happens.

I've been with Eleutian now for almost a year.  I left Microsoft to help develop this English eLearning solution that is SpeakENG.  I'm now leading a small team of developers in Seattle.  We started this blog to talk about some of the things that we've been doing here as well as other random things that're just on our minds.  So that's about it, we'll see what happens.