Archive for October 2007


Inline Scripting

October 16th, 2007 — 12:05pm

This is an interesting article from Rob Conery on the virtues of inline scripting; which, of course, has received a bad rap in recent years but still has a place in the pantheon of development technique.

http://blog.wekeroad.com/2007/10/15/crazy-talk-inline-scripting-and-code-behind/

Comment » | Uncategorized

Perfect Christmas Gift

October 10th, 2007 — 1:32pm

Anyone who gets me any of these for Christmas is tops in my book:

http://www.thinkgeek.com/geektoys/plush/6708/images/

Comment » | Uncategorized

jQuery Event Binding vs. ASP.NET AJAX UpdatePanel

October 9th, 2007 — 1:05pm

UPDATE (12/5/2008): An alternative solution to this issue is found in a more recent post here:
http://www.thegrubbsian.com/2008/12/jquery-vs-the-aspnet-update-panel-revisited.html

While this is a simple topic, it is one that tripped me up and since the documentation for ASP.NET AJAX is pretty poor, I thought I'd share how I worked it out.

One of the great advantages of using a JavaScript library like jQuery is easy event binding.  In jQuery you can bind an event in a cross-browser compliant manner with very little code:

$("someElement").click(function() { alert('I'm Clicked!');});

Another convenience of modern JS libraries is a loaded event, basically detecting when the browser has finished receiving and parsing the DOM from the server.  For example, in jQuery we can test for DOM completion thusly:

$(window).ready(function() { ... });

Anything within the function here will be executed only after the entire DOM has been downloaded and parsed by the rendering engine.

Now, when you wrap parts of markup with an ASP.NET AJAX UpdatePanel you create a scenario in which a certain portion of the DOM will be reloaded asynchronously while other parts are not.  Even though you will often be merely updating nodes within this area of the DOM, the UpdatePanel is heavy handed…it basically just wipes out whatever was in there and replaces it fresh from the server.  When this happens all your fancy events bound to those elements are blown away.  Thanks UpdatePanel!

Happily, there is a solution that works with any library, not just jQuery.  You will need to abstract your jQuery event bindings away from their handlers into new JS functions.  For example:

$(window).ready(function() {
    $("#someElement").click(function() {
        alert('I've been clicked!');
    });
});

would become:

$(window).ready(function() {
    $("#someElement").click(function() { SomeElementClicked() });
});

function SomeElementClicked() {
    alert('I've been clicked!');
}

Next, we need to replace the jQuery "ready" block with a function that automatically gets called by the ASP.NET AJAX client framework whenever a postback occurs (sync or async).  So our script would now be:

Sys.Application.add_load(WireEvents);

function WireEvents() {
    $("#someElement").click(function() { SomeElementClicked() });
}

function SomeElementClicked() {
    alert('I've been clicked!');
}

Now you can continue to use jQuery to bind events (and skip using the convoluted ASP.NET AJAX way) and use the UpdatePanel to surround jQuery bound DOM elements.

8 comments » | ASP.NET, jQuery

My Page Just Had Deja Vu

October 5th, 2007 — 1:42pm

One function whose absence I find annoying in ASP.NET is the ability to easily return to a previous page and reload its state.  I recently needed this functionality in a project for a course registration application I was building at work.

The basic scenario is this:

  1. User enters some search criteria on the Course Search page and a list of matching courses is returned.
  2. The user selects a course and is directed to the Student Roster page for that course.
  3. The user then selects a particular student and is directed to the Student Maintenance page.

Now, the user will almost always need to get back to the Student Roster page, and maybe even the Course Search page after making changes on the Student Maintenance page.  However, they don’t want to start the whole process over back at Course Search each time.

So, I tried a number of ways to accomplish this in a generic fashion, the first being a convoluted method using the PageStatePersister class to pop the page’s ViewState into Session and bring it back when the user returns.  However, this can be problematic because the page is unaware of what’s going on in the application outside of itself.  In other words, data may have changed or the user may have returned to this page through a non-linear route and now needs a different set of criteria; they don’t want the same options they chose before.

So what I came up with was a simple solution using the query string and a ReturnUrl parameter.  I’m sure we’ve all seen these things gumming up query strings around the web.  While it does tend to make your URL rather intense, it is an effective method and it’s easy to see what’s going on.  So here are the requirements I set up for whatever method would implement this functionality:

  1. The method must be able to pass forward a ReturnUrl parameter which can hold both control values on the original page as well as any query string variables which were passed to it.
  2. The method must be able to handle n forward progressions and likewise be able to link backwards n times without losing anything along the way.
  3. When a page reloads from a ReturnUrl the method must be able to set values on ASP.NET  WebControls on Page_Load.

So, I wrote a class which inherits from System.Web.UI.Page called DejaVuPage (an apt name I thought) which encapsulates this functionality.  The code for this class can be found in the App_Code folder in the zip file which accompanies this post as DejaVuPage.cs.  Essentially, there are four things any page inheriting from DejaVuPage can now do:

  1. Set a list of controls to be included in potential ReturnUrl params.  This is done by adding control IDs to the DejaVuPage.ReloadableControls (ArrayList) property.
  2. At any time get what the current ReturnUrl parameter would be.  This is done by getting the DejaVuPage.ReturnUrl property.
  3. Redirect to the previous page by calling this.RedirectToReturnUrl().
  4. Reload a page’s controls from a ReturnUrl by calling this.LoadFromReturnUrl().

The ASP.NET sample project included in the post has a good example; run the app, enter some criteria on each page, then when you get to the end use the ‘Go Back’ links each previous page will reload it’s controls as you left them before.

I’m sure someone can improve my code, so if you see somewhere where this concept could be refined, please let me know.  I hope some of you find this useful.

Download DejaVuSample.zip

Comment » | ASP.NET

Back to top