Upload multiple files using jQuery and ASP.NET

A few weeks back I needed a control that allowed me to upload multiple files to a SQL database going through an ASP.NET ashx handler. Also, the whole control needed to be implemented client side and the best option if using jQuery.

I spent lots of time trying to find some good control that didn’t used Flash. Most of the controls available out there were pure based Flash applications or a combination of jQuery + Flash. None were pure jQuery and supported the option of multiple files. Then I found Andrew Valums jQuery upload control. It was pretty easy to install and configured. The only drawback is that uses iframe for uploading the file, but this is transparent to the end user, so I decided to give it a try.

Here’s how it works:

Download the control

Go the website and download the control. Keep in mind there are two versions: one GPL and another one with the MIT license. I went with the one with the MIT license. You can download it here.

Place the control on your page

Use the following HTML code to place it:

<div id="uploadRegion">
 <div>
  <input id="button3" type="file" />
 </div>
 <p>Uploaded files:</p>
 <ol id="infoUploadedFiles" class="files"></ol>
</div>

jQuery code to create the control

new AjaxUpload('#button3', { action: 'filehandler.ashx',
                      name: 'myfile',
                      data: { '' },
                      onComplete : function(file, response){
                          var fileResponse = $.parseJSON(response);

                          $('<li></li>').appendTo($j('#infoUploadedFiles')).text(file);
                       } 
                  }); 

ASP.NET code to handle and receive the file

After receiving the file in a byte array proceed to save it to the hard disk or a database, as needed.

Transalating a webiste automatically based on users IP address

Why is it that sites that provide localization always try to assume that the best content for you is the one based on your location?

Most people sometimes aren’t in their hometown. They could be on a trip to Asia or the middle east, but this doesn’t mean that when researching for a site or information, they want to see these sites in mandarin or in Arabian.

I may say that the majority of users try to look information first in English because the majority on sites are already in this language. You have more probabilities in finding what you need when querying in English.

What I’m saying is, don’t try to provide information on your site with automatic translation based on the visiting’s user IP address. Give the information in your primary language, be it English, Spanish, French or Portuguese and then give the user the option to select the language in which they would like to see the website and save that on cookie or the user profile for when they comeback. If the user queries google in English and when it enters your site it is then automatically translated to Spanish because the user happened to be in Cabo for vacations, he might leave, inferring the original language of the site is Spanish.

A different approach about passwords in registration forms

With the hacked of Gawker Media sites and the release of a list of users and passwords stored on the sites, people all over the Internet started reacting to the news and offering techniques on how this can be resolved.

Some of the proposed techniques include getting rid of the user database implemented on many websites and let an external application handle the customer login using credentials from others sites like Twitter, Facebook and OpenID. In my personal opinion, I really don’t like any of these mechanism because I really don’t trust these companies. Your could argue that they might have better protection than some guy’s new web service that just launched in 30 days to test an idea. Maybe it’s true, but also this guy might have a better mechanism to prevent this kind of leaks than the big companies.

Also, I think it’s not true that having a single point for user authentication is going to resolve the whole issue. Compare it with credit card fraud. Do you think you can solve the credit card theft problem by just having ONE card with a $300,000 limit than having multiple cards with, say $5,000 limits? If someone steals one of the cards, you only loose the 5,000. If you someone steals your ONLY card, you might loose $300,000 and you’re left with NO card. This is call spreading the risk.

A different approach that we use on our sites is to generate a random and strong password automatically for the user and send it to their email. We give them access to what they’re requesting on the site with just entering the email (and other information if necessary) and then email them the password generated. When they decide to come back to the site, they used the autogenerated password. They can change it if they want, but we took that step out of the funnel (guessing and thinking what password to put on) and just let them proceed to perform the requesting transaction and letting them now in an email how to continue using our sites in the future with their new strong password.

Why application localization should start in the design stage

When I start developing and throwing out code, I can tell you I’m too concentrated in the features and how I want things to work out. Always testing and debugging and running around different possibilities in my head on how that piece of code could go wrong.

When writing elements on the interface, I just tend to place the needed controls or the html tags on web pages and add the labels to the respective controls. The labels just pop out of my head without even noticing what I’m writing. Most of the time I’m just thinking how the feature is going to work with the control.

So, when your application is finished, features are implemented, and then we begin with the cosmetic work. This is when the problem arises. If you intent is to offer your application in multiple languages, then localizing the controls and html pages is not part of the cosmetic work. The only way to localize your app when all the labels are hard coded is to make a copy of the web page or control, with the same code, and start changing the labels manually.

That’s why I always have a localization strategy before beginning throwing out the code. Even if you decide how the language engine is going to work after you’ve hardcoded the labels, the simple task of changing them to the variables is exhausting. After months of going through this process with some applications that didn’t have a localization strategy, I’m stilling finding hard coded labels.

Here are some simple strategies I’ve used:

1. Desktop applications (server side): I always try to save the labels on the database repository of the application. Using this technique, I can add languages and modify labels without having to compile the application. Sometimes, developers embedded the label files in the executable itself, the drawback with this technique is having to recompile for adding new languages. With the database option, you just have to create generic functions to get labels out of the repository. I usually have four special fields for identifying the label: the screen or page, the name of the control, the language and the label value. It’s easy to find labels for a specific screen or page this way and save them on memory. Just one query to the database.
2. Desktop applications (client side): I don’t like very much this technique, storing language files in the application local folder. For me, it seems prone for failure: what if the user deletes the file, what if the user opens the file and changes the labels, etc. If you need to store files on the hard disk, try to encrypt them and have some default language embedded in the app executable just in case the language files are deleted.
3. Web application (server side labels): Again, the labels are stored in the database as in the previous technique, although some complications might arise. Remember getting a label value involves making a query for three fields in the database: the page, the language and the control. You might be able to make a function that gets all labels for a page and dynamically find the controls and assign the labels, but I always find it difficult to loop for controls in the page. On our projects I use the Custom Expression Builder functionality from ASP.NET. I’m able to assign the label in the HTML page and dynamically the .NET Framework detects the page and the label is passed as a parameter and then goes to the backend database to get the information. This way there’s never a hard coded value in the HTML. The only issue is that every label is a different request to the database. For one page with 20 labels and a thousand users seeing the page it comes to 20,000 queries to the DB for labels. What I did in this case is to implement a caching mechanism to store the label values in a file on the server. First I check the cache, and as a second option go to the database. Labels do not change that frequently, so the cache can last for a whole day without any issues. This is the technique used on all our websites (SkyXoft, RequestSpot).
4. Web Application (client side): This is the technique used on our request and task management software. All labels are stored in javascript files (one for each language) defined as constants. In the application, on HTML pages, using some simple jQuery I then refer to the constant and assign it the html element in question. It is fast and simple. I determined the language on server side and include the javascript library (the script tag) in the html.

Any of these techniques should be enough for localizing an application. The most important issue here is to plan for language support before coding starts. Doing it afterward is a never ending work. Hidden hard coded labels appear every day.

If you want more information about the code we use or you have any other technique for localization, let me know in the comments.