Category Archives: C#

jTemplates is a jQuery plugin and template engine for Javascript. If you keep up with Dave Ward and/or Rick Strahl you may already be familiar with jTemplates as they have both highlighted the plugin on their respective bolgs. About 1.5 months ago, however, I got into the action and started using jTemplates in conjunction with jQuery, AJAX and Json to dynamically populate dropdowns and tables on the client side.

As you’ll see in the examples, jTemplates provides custom syntax to do such things as iterate through Json data and populate a predefined template. Once you get a grasp of the syntax and the proper usage, you will be ready to roll. Getting started is easy — just download the latest jQuery and jTemplate bits and reference them within your html or aspx file.

Next, you need to define and host your templates. In the included sample project, I’ve defined two templates to aid in the population of my dropdown and my table respectively. Here you will notice the dropdown template merely adds a singe “Select One” entry and then iterates over all project results adding a new option for each:

And the following table template is a little more complex but still very to interpret. Here, we are iterating over each task row and appending a new row to the table for each. Notice there’s a MAIN template and a ROW template. The MAIN template passes along the current record to the ROW template. The ROW template sets the appropriate class (think table zebra stripes) and column values based on the current “cycle.”

How’s about hosting the templates? You have a few options. First, you could save the templates off in their own file. This is the approach Dave Ward took in his article. Though this approach is clean, it doesn’t perform all that well. The preferred approach is to “embed” your templates within the html/aspx file by wrapping each of the above templates with a script tag like so:

As shared on Rick Strahl’s post, this is the preferred approach as using <script type=”text/html”> that allows hiding any markup in the document without interfering with HTML validators. The script can be accessed by its ID and the content retrieved using the jQuery .html() syntax.

Once your template is in place, you simply need to assign your template to your container (a div) and then process the template using your Json data. As noted above, you may reference an external template using the following:

$('#tasks').setTemplate('Template.htm');

Or you may select the template from the html/aspx itself:

$('#tasks').setTemplate($("#TemplateResultsTable").html());

Again, the preferred approach is the latter. In either case, you process the template data (results) as follows:

$('#tasks').processTemplate(results);

A quick note on .processTemplate. You don’t actually have to provide any data. You can send null into the processTemplate method if, for example, no processing is required. In the downloadable example, I create a static template which acts as a place holder when my page first loads and no table data is available. Here’s the sample template and javascript:

Before I wrap things up, I should mention the downloadable sample project doesn’t only show off jTemplates. It also demonstrates how to use jQuery and an “parameterized” HTTPHandler to pull back Json data which is somewhat an extension of my earlier HTTPHandler post.

You may have noticed there’s a comment for nearly every code block. At first, one may find the comments redundant and unnecessary, but really they are call for help. A code:comment ratio like this usually indicates you really need to focus on what’s happening with the code because if you aren’t paying attention, bad things might happen.

As you have undoubtedly concluded, there’s a lot of overhead associated with returning JSON data from an ASPX file. This statement is especially true if you consider the alternative, an HTTPHandler. Here’s a cleaner, best-practices approach which provides the same outcome with less code, comments and risk.

If you are already accustomed to using generic handlers to stream back images, XML, JSON data, etc, this post was probably a bore. But it’s sometimes easy to forget what’s available to you in the vast .NET stack, so hopefully you appreciate the friendly reminder. In either case, it still surprises me how many examples use the ASPX approach. In fact, the practice is common enough that I sometimes wonder if there’s an HTTPHandler gotcha to which I’m not privy . If I am missing something, please let me know.

If you’re still interested, attached you’ll find code which populates two jQuery Flexbox controls using JSON data provided through an ASPX and ASHX files. This may be worthwhile download if you’re interest in the generic handler code or you want a further look at Flexbox in action after last week’s post.

Do you need a quick and cache wrapper class? Here’s a static class which I included in my more recent C# web application. You’ll notice the class uses generics to allow for some, umm, generic functionality.

Notice how I’m grabbing the cached value, storing it in a local variable and then checking if it is equal to null rather than using the CacheHelper.Exists() method. If I used the CacheHelper.Exists() method, the cached object could expire between the time I check its existence and the time I get its value through the CacheHelper.Get() method. Therefore, the above approach is the safest strategy to use when retrieving cached values. CacheHelper.Exists() should really only be used for quick existence checks which are unrelated to the fetch.

But if you want to use the code CORRECTLY there’s a catch. Did you notice the “class” constraint on the CacheHelper.Get() and CacheHelper.Add() methods? I did this because you can’t always return null from a generic method. If the return type were always a reference type it would be fine, but comparing a non-nullable value type to null would throw a runtime exception or would always evaluate to false. Therefore, I’ve constrainted CacheHelper which limits its functionality but unsure safe use of the cache. If you’re feeling dangerous, you’re welcome to remove the constraints.

I’ll update the library once I come up with a good work around. Speaking of, any suggestions?

Let me know if you have any questions and/or this type of post is helpful. Thanks.

UPDATE 12/10:

After further review, I’ve removed the “class” constraint from the CacheHelper. The Get() method now follows the common Try(x, out y) pattern where x is what you wish to operate on, y is the resulting value and the method return success or failure. Here’s a sample call:

Many of my C# methods include what is referred to as a guard clause. It isn’t a complicated concept. Simply the first few statements of a routine validates passed-in parameters and/or state of the object and immediately returns an error or gracefully exits to the function is constraints aren’t met. If I’m not mistaken, this plays nicely with the Design by Contract approach to software design, but I no expect on the subject. The bottom line is, a guard clause can really tighten and clean up your code because it will undoubtedly eliminate any number of nested conditional statements.

Much cleaner, eh? And that’s only two conditionals! Back to my point. Many of my method include guard clauses. Today I needed to validate that all three string parameters had a value. In other words, each string’s length was greater than 0.

There’s a ton of information online about exporting a DataGrid or GridView to Excel, but most variations do not consider the GridView may reside within an UpdatePanel. It goes without saying, but I was disappointed when I recently dusted off my “Export GridView to Excel” code snippet and encountered a number of exceptions. So I revisited a number of links and I collected a working solution. If you need a “simple” way to export your GridView to Excel and you are using an UpdatePanel, I hope the following code finds you well:

Update: 7/30/2008

I previously noted that SetCacheability doesn’t seem to make a difference. Well, I was right…until I deployed my code to a site behind SSL. As it turns out, in order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load.

If the file is not stored to disk, this operation fails. When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.

RESOLUTION: Web sites that want to allow this type of operation should remove the no-cache header or headers. In other words, comment out the following line of code particularly if you are running under SSL:

Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);

Additional Comments

Per Jinath Blog, if you are using an UpdatePanel, you may get a System.WebForms.PageRequestManagerParserErrorException exception. The solution is to add a PostBackTrigger and give it’s ControlID as the excel export button’s ID or you can move your excel export button out side of the update panel. I verified both options and they work great. I ultimately went with the former option as such:

Per ASPAlliance, you may encounter issues a number of issues which require the following solution. Check out the link (and the comments) for more details if you get stuck. I only encountered #1 on the list.

You may get an exception which states your Control ‘Grid’ of type ‘GridView’ must be placed inside a form tag with runat=server. I overcame this by dynamically adding a form to the page and then the GridView to the form before RenderContent(). This solution came per the aforementioned post’s comments.

You may need to included the following page directive: EnableEventValidation=”false”. I didn’t need to include this directive.

You may need Override the VerifyRenderingInServerForm Method. I didn’t need to do so because I added my GridView control to a “mocked” form.

Per Dipal Choksi, one can format the spreadsheet results in a generic manner by replacing all controls within the GridView with Literals. This is reflected in the ClearControls() method above. My prior implementation merely cleaned up the links associated with the sort functionality tied to the sortable headers. This solution tackles all cells.

You may have noticed that my recent posts have been short and provide little more than featured code. This is a new approach for me. What do you think? Should I continue to pepper in these quick code snippet posts with little commentary?