On Friday June 17 we released our first jQuery extension as Open Source. The extension is called Wajax for jQuery and in short, it’s an extension that allows you to synchronize the (otherwise asynchronous) callbacks from a number of simultaneous ajax requests. Wajax also ensures that the callbacks are called in the same order as the requests have been started. You still get the full benefits of normal ajax programming as all Wajax requests are executed asynchronously – Wajax just sort of adds an extra layer of bookkeeping to help you (the programmer) so you don’t have to worry about keeping track of which requests have completed and which have not.

Where can this be applied and what’s the benefit?

Imagine you have to implement a widget for a website. The widget has to be loaded dynamically at an arbitrary point in time after the page has loaded. Also imagine that the widget needs data from two different data sources before it can be rendered out. On top of that you have already decided that you are using a jQuery templating enigine on the rest of your site and for consistency you want to use templating for the widget as well.

So what are we looking at here? Well, the data needs two requests – one for each datasource. It might also make sense to load the template for the widget dynamically meaning one more request. That means we have to make three ajax requests in total before we can render our widget. Actually it’s not enough to make the requests. You have to make sure that they have all finished before starting the rendering process. Now, that is by no means a huge problem to solve but Wajax will help you out and make it very easy to handle this situation.

For more information about how that actually works I suggest you check out the documentation on the project’s GitHub page which can be found here. Hopefully you will also download the plugin and check out the included example.

It’s worth noting that the first version of this code was actually created to solve a specific need for a website we created for a client. After the website was launched Valtech invested some time in packaging the code into a small jQuery extension, documenting it and putting it out there on GitHub.

Why jQuery and why Open Source?

At Valtech we have made a strategic choice to go with jQuery for the front end development in our web solutions. In reality there weren’t that much of a choice to make as jQuery has become the de facto market leader when it comes to javascript frameworks for frontend development. It’s the javascript framework that everybody knows and it has a huge backing in the open source community. Even Microsoft is including it in their MVC framework.

Just as we made the choice of using jQuery in Valtech we also decided it was time to join the Open Source community. We get huge benefits from using and learning from all the Open Source stuff that’s out there. This we way we can pay back a little to the community.

Off course, we also believe it makes sense from a business point of view. For instance, when we need to build something that’s not already out there in the Open Source community we could choose to put that into our own library. However, when it comes to frontend development the world is moving very fast. Next time we would need to use something similar we would still have to search the Internet to see if something better had come up in the meantime. Chances are that something close would have been built by somebody else facing the same need as we did – and their code might already have gained a following. That quickly makes maintaining your own “private” library of code seem a bit redundant.

That’s why we have opted to share some of the more general frontend components we develop in-house. Our hope is that you will prove this to be the right decision by using and contributing to the components we release as Open Source starting with the Wajax for jQuery extension.

A classic problem, or challenge if you are a glass half-full type of person, in software development is how to target multiple environments. By environments, I really mean different machines. Machines for development, for testing, for staging and for production, e.g.:

The problem

In some areas of software development, this is a problem of supporting different hardware setups, but in web development we (most often) only have to worry about different database connection strings, mail server setup, paths to e.g. upload folders, and similar configuration differences on different environments.

Several solutions to this problem have been suggested, but common for all solutions is a goal to automate this process of supporting multiple environments without having to manually figure out which configuration bits that needs to be flipped.

Furthermore, as developers we are used to working by contracts. At a very lowest level we have an unspoken contract with the compiler, making sure that we keep to the rules of our language of choice. Our types and methods too define contracts on what we are allowed to do. Webservices rely heavily on contracts, just as any services in the real world do. Surprisingly though, while our applications and websites more often than not rely on configuration files to keep them running, our configuration files are just flat files. In other words, there is no contract preventing us or at least warning us from making errors that in worst case scenarios could bring everything crashing down around our ears. Solving this part of the problem is hard. While you can build procedures to automatically check that everything looks nice, actually validating the data is a topic worthy of a book in itself.

Solution

Automatically building environment specific configurations is nothing new, in fact a tool is built right into Visual Studio 2010.

The Web.config transformation tool in Visual Studio allows you to:

• set attributes
• remove attributes
• delete nodes
• replace nodes
• insert nodes

in your Web.config file. This is great.. as long as all you require is the ability to modify your Web.config file from environment to environment but if either of the following statements are true:

• I keep certain configuration bits outside the Web.config file
• I’m not .NET web developer using Visual Studio

this solution is not for you. Not to mention, this does not ensure that aconfig file for a specific environment is not missing a vital property.

Our solution

While our work primarily involves ASP.NET web development, the projects we work on require a much high degree of configuration customization than the Web.config transformation tool described above facilitates.

Our goal was to create a configuration framework that would provide us with a high degree of customization and at the same time be statically compiled, preventing us from building and then deploying a bad environment configuration.

We ended up with a solution looking something like the figure below:

In the figure above, the boxes on the left (“Templates” and “Environment specific properties”) are especially interesting.

“Templates”, surprisingly, contains templates. For example, it might contain a Web.config template in which connection string values are not defined. It could also contain a license file template, in which the license key was not defined. Instead of defining the environment specific values, that is connection string and license key values, a uniquely named property is written. This property will then be substituted for an environment specific value by the configuration framework when the project is built.

At build time, we then invoke the configuration framework, which collects all the templates and attempts to populate them with properties from a specific environment configuration. Now, if a property is not found, the build will fail and warn us about the missing property. This is great, since we only have to maintain one configuration file (the template), but can still modify and build it across multiple environments and at the same time ensure that all configuration files contain all required properties.

The figure below illustrates this process:

Hopefully this has piqued your interest. If so, stay tuned for the next post in which we will go into the technical details of our solution and best of all, offer it to you free of charge.

Read the next post here: Targeting multiple environments and machines – part 2/2