Localization editor for Applications

I don’t realy know what to do right now, so I thought I’d share some of the latest work on RemoteX Applications.

RemoteX Applications has support for multiple languages being used in the same hosted installation. Basically we install a set of languages for each installation. Now most of our customers want to make some changes to the standard localization. These changes were made by our operations team, who would verify the installed language on each system installation.

While this is all fine and good, the problem is when we update the localizations. All of a sudden there is a lot of different customer specific language packs which needs to be updated with new keywords and translations. Others might need to be removed.

What we have done now is to separate out customer specific changes from the standard language packs. The operations teams can handle the standard language packs and the customer specific details are separated out and can be managed independently, thus not slowing down upgrade scenarios.

But it doesn’t end here, I finally got some use for my JQuery work for RemoteX Applications. I just completed a minor web application to handle the customer specific changes in an AJAX interface, talking with our REST-service.

What is fun about this application is that the idea just popped into my head a few days ago. The implementation time is around 2 days of TDD work. There are roughly 84 tests checking the Javascript using QUnit.

There are two things I especially like with the implementation. One is that the separation of concerns was separated out quite nicely, this was greatly beneficial for the testing. I also noticed that there are some quirks in the interface which wouldn’t have been there if I hadn’t used TDD.

I had an idea of how I wanted to make the interface from the start. But my initial plan was to write it using WPF and host it in the Windows Client. However since I made this in JavaScript using JQuery the approach was a bit different. I’ll walk you through roughly how my plans evolved during the development process.

1. The greatest risk I was was with the XML generation which was to create the messages I sent to the server. To mitigate this I started by isolating this functionality in a “class”.
2. Once I saw that the tests were achieving the behaviour I needed from the XML Writer I started with the interface. I knew roughly how I wanted it, so I focused mainly on the behaviour. I work heavily with DIV’s, if I know I need to display something I add a DIV for it. This allows my to do formatting later as a separate step.
3. The third class was the controls for selecting languages and buttons for loading. I knew from the start that I didn’t want any logic in these classes, instead I wanted to create a Controller pattern to handle all logic. This turned out great.
4. The fourth class is where I started to notice some interesting synergies popping out from the code. The isolation level of the components allows me to reuse previous components to solve business needs through composition.
5. Lastly, the controller logic is tied in to complete the application. The controller mainly ties all the UI together using AJAX. Interesting to note here is that I tested the AJAX by mocking the AJAX calls. Previously I’ve tested AJAX for doing GETs by having a static XML document to fetch. Testing it with mocking was quite easy and allowed for different kinds of testing.

The editor is now tested to be working in IE8, Chrome and FireFox.