In this article we will be looking at a different type of architecture. One in which we utilize jQuery’s ability to easily transfer data (via Ajax and JSON) from the client to the server. We then use ASP.NET and LINQ to SQL to query the database and return a collection of data which gets (automatically) serialized to JSON and sent to the client. The benefits of combining these technologies include: more responsive applications, more processing on the client, less processing on the server and reduced network traffic. Everything runs faster and uses fewer resources.

Still not convinced? Here are some additional benefits of this architecture:

Benefits of the Architecture

1. Unlike an ASP.NET UpdatePanel we only pass what we need; we only receive what we need. We don’t pass ViewStates, in fact we don’t even have a ViewState. We also don’t pass entire HTML chunks and receive HTML chunks we don’t use. For more on this; read: Why ASP.NET AJAX UpdatePanels are dangerous.
2. By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests that’s included when you use ASP.NET Ajax.
3. Less dependencies – because all our code is simply xHTML we could switch to a PHP or a Java backend and none of our code for the UI would have to change. That’s right, there are no server-controls; that means no GridViews, no Repeaters, no ListViews, nothing that uses runat server will be found on the page. Not even a ScriptManager.
4. Usability – We can create RIA interfaces AND maintain usability, giving us the best of both worlds.
5. Cross-Browser friendly – We use nothing but xHTML code and jQuery which works across browsers.
6. The entire presentation for the UI is done via CSS. Change the CSS and the entire UI can look different.
7. We maintain a ‘Separation of Concerns‘ – this means we have 3 distinct and wholly separate code bases. A content or HTML level. A presentation or CSS level and a behavior or JavaScript level. We don’t have code mixed together in a web-page jambalaya.
8. Switching architectures from Web Forms to MVC is a breeze.

Hopefully you are salivating at these benefits enough to decide to get your feet wet and follow along.

In this article will be leveraging these technologies to build a grid (or what looks like a table). Later on, in future articles, I will then show you how to implement sorting, paging and filtering on the grid. I have divided this article up into four sections: 1. Sever-side code (ASP.NET). 2. HTML 3. jQuery and lastly CSS.

(more…)

jQuery, a lightweight (only 19kb in size) JavaScript library has become my new best friend. It's like mushrooms to Mario. Obviously I'm not alone since Microsoft is now distributing jQuery with Visual Studio (including jQuery intellisense). If you are using the new MVC framework from Microsoft then you will no doubt become familiar with the intricate workings of jQuery.

jQuery is not all that difficult to learn. The biggest thing you have to understand is all the different "selectors" that are available to you. Using selectors developers can query, in a CSS like way, for HTML elements, and then apply "commands" to them.

For example, the below JavaScript uses jQuery to find a <div> element within a page that has a CSS id of "rightSide", and shows it and "leftSide" and hides it.

As another example, the JavaScript below uses jQuery to find a specific <table> on the page with an id of "datagrid1", then retrieves every other <tr> row within the datagrid, and sets those <tr> elements to have a CSS class of "even" - which could be used to alternate the background color of each row:

This next example gets all links <a> in a specific <div> and attaches an onclick event to them:

Being able to traverse the DOM and locate HTML elements to attach events, behaviors, animations and CSS is priceless. But what about ASP.NET controls like the RadioButtonList, GridView, ListView, Repeater, and many others that we as developers like to bind to? How do we traverse them when they all get their ids auto-generated? That's what we will look at now! And with jQuery it's not that hard!

(more...)

In this article you will learn how to send email using ASP.NET. Yes, there are plenty of other articles that cover sending email via .NET, but after spending a day doing research, I was amazed at how many articles failed to provide either a correct solution or a real world example. I found that many articles suggest you create your HTML email by using a string with the HTML markup in it. That's crazy and not at all a real world solution, at least not for most situations. In this article we will look at a more realistic solution. One in which we use a regular HTML file as our template for the email. The template file will be a standard HTML file with the exception of some placeholders that we will use to populate our content and images right before we send the email. Think mail-merge in Microsoft Word. Finally, we will also learn how to send the email in such a way that if the email recipient's mail-client can't render HTML they will get an alternate plain text version.

Let's start by looking at the code in its entirety; the people that just want to grab the code and use it can do so. I will then explain the code.

(more...)

I love ASP.NET, but one thing I find extremely frustrating is dealing with the automatically generated ID properties that it places on page elements.

For example, let's say you have a div with an id of "contentTop" like below:

Because you have made the control a server-side control by adding the runat="server" attribute it will now be rendered with a different ID when it hits the browser (view the source code and you will see). It will get rendered as something like this:

This is because ASP.NET generates its own IDs to ensure that every element on the page has a unique ID. Developers that work with JavaScript and CSS will immediately see the problem. This causes difficulty when using JavaScript and CSS which rely on those IDs to reference elements, as they can't easily predict what the generated ID will be. When it comes to CSS specificity the ID selector is extremely useful. In addition, anyone that uses JavaScript knows that getElementById (or one of the JavaScript library ways) is the most popular way to target an element. So why the hell does ASP.NET do this to us? Honestly, I can't really tell why, other than the fact that they must not trust us enough to be able to uniquely ID our elements ourselves.

But I don't want to just complain here, I would like to provide some solutions too.

Solution

The solution will be found in the ClientID property of the server-side control. The ClientID property represents the ID that ASP.NET will use for the element on the client.

Using the ScriptManager we place the ClientID in a hidden form field. This can all be done in the code-behind file by using the following code:

Be sure to have included the ScriptManager to your page, like so:

Now we can use JavaScript to retrieve the value from our hidden form fields.

That's it, if you know of another way, please let us know.
Happy coding.

1. Automatic Properties

Automatic properties provide you with a shorthand for defining a new property. No more do we have to create the private property and then use Getters and Setters to access and set that property. Here's the old code:

Now here's the code using automatic properties:

Oh my! How nice is that? The C# compiler creates the Getters and Setters and the private fields for you automagically!

(more...)

This past week, I have been undergoing a week of rigorous training learning the key differences between .NET 2.0/3.0 and .NET 1.1. For the past two years our company has been working with the 1.1 framework, and is now migrating towards the 2.0/3.0 framework. This week the instructor said something I knew, but was glad to be reminded about. It wasn't even a .NET oriented question, it was an object oriented question that does not apply to one specific language, but to all OOP (object oriented programming) models in general.

What is the difference between a struct and a class? When should you use a struct versus a class? How do you know?

(more...)

If you hang out on enough web development forums, mailing lists, or chatrooms, you'll eventually get asked this question:

What language should I use to program my next project?

As someone who has been on a few of said forums, mailing lists, and chatrooms for a while now, I hate seeing this question. Yes, it comes around a lot, but repetitiveness isn't what bugs me about it. What bothers me is that there's usually very little background information attached to that question, which makes it as open-ended as asking what mode of transportation you should take to get to the store. I can tell you anything from a skateboard to a jet and either vehicle can get you to the store, but to give you the best answer I need to know how far you have to travel, what you plan on buying, and how much money you have, among other things. The same holds true for the programming language question, so let's look at some factors that can help you choose which language to use on your next project.

(more...)