The original design concept was for a web store framework I was working on.  I wanted each store be able to easily change their javascript based themes without making changes to the javascript files for the basic theme.  This made for a much easier file based deployment of new versions to each store.  The obvious downside is that you’re downloading lots of extra javascript, particularly if you’re turning features back off that were in the basic theme.  This type of functionality is only useful in certain cases, and is never the most efficient system possible with regards to performance and bandwidth, just maintainability.

This new release still maintains that basic functionality, but now I address a more common concern as well, applying themes to AJAX updates.  In order to support this, I’ve added several new features.

• $.themescript.exec now accepts a context parameter.  This can be a jQuery object or an HTML DOM element, just like the context to jQuery’s jQuery(selector, [context]) selector function.  All registered functions will receive this context as a parameter, and it will be automatically used as the context to selector-based theming to restrict the elements returned.

• themescript is a new function added to jQuery objects which allows you to execute the themescripts against a specific jQuery object.  $(‘#selector’).themescript() is equivalent to $.themescript.exec( $(‘#selector’) )

• themescript( url, [data], [callback] ) works just like the jQuery load method, except that it will automatically run themescripts against the updated HTML if the request is successful.

You can also easily add support for jQuery.themescript to ASP.Net AJAX partial page updates (a.k.a. UpdatePanels).  Just add this script code to your files and the themescripts will be automatically executed against any UpdatePanels which are changed during an asynchronous postback.

var prm = Sys.WebForms.PageRequestManager.getInstance();
prm.add_pageLoaded(function(sender, args) {
    var</span> updated = args.get_panelsUpdated();
    if</span> (updated && updated.length) {
        $.themescript.exec($(updated));
    }
});

Here are the links where you can access the GitHub repository or download the files:

GitHub
Download

The only downside of using jQuery with ASP.Net is the lack of integration.  They now include a vsdoc file which helps with Intellisense, but there’s a long way to go.  For simplicity, I’m still using Microsoft’s AJAX code for their page methods and UpdatePanels, and primarily using jQuery for the client side controls and animations.

I’ve written a library to help with the creation of ASP.Net server controls that utilize jQuery.  I’m calling it, very creatively, jQuery.Net.  You can access the code and binaries for the library on github, the link’s below.

jQuery.Net Git Repository

GroupedUpdatePanel.zip
]]> http://btburnett.com/2008/04/fix-to-groupedupdatepanel.html/feed 0 http://btburnett.com/2008/04/grouping-update-panels.html http://btburnett.com/2008/04/grouping-update-panels.html#comments Fri, 25 Apr 2008 10:19:00 +0000 Brant Burnett http://www.btburnett.com/?p=8 Without a doubt, AJAX is one of the most useful web development tools out there. Through AJAX, we finally have a method for developing web pages with robust user interfaces.

The most common and simplest method of AJAX development on ASP.NET is to use the UpdatePanel. While the UpdatePanel creates a lot of overhead, it is very simple to implement. However, sometimes you will have multiple UpdatePanels on a page that relate to each other. In order to reduce your overhead, you will probably want to set thier UpdateMode to Conditional. With the Conditional UpdateMode enabled, they will only update under three conditions (note that nested UpdatePanels are a bit more complicated):

1. A child control of the UpdatePanel performs a postback, and ChildrenAsTriggers is true
2. The Update method is explicitly called.
3. A manually defined trigger is fired.

However, this doesn’t help with firing the other UpdatePanels on the page that are related. While you can update the other panels manually using the Update method or triggers, that can potentially be a lot of work and difficult to maintain.

In order to address this, I’ve created a simple GroupedUpdatePanel. It has a GroupName property which is used to group multiple GroupedUpdatePanels together. If any one UpdatePanel in a group is updated as part of an asynchronous postback, they will all be updated.

There are two important restrictions to note. First, you must set UpdateMode to Conditional. If any one GroupedUpdatePanel in a group is set to Always, they will all update every time. This is a result of the limitations of inheriting from the UpdatePanel class. Second, all of the UpdatePanels must be created and on the page at the time the PreRender event occurs. I’ve seen some reports on the web of certain situations where this is not the case, though I haven’t tested for any of it.

You can download the source for the control here. Feel free to use it in your own applications.

UPDATE: Please see updated version here ]]> http://btburnett.com/2008/04/grouping-update-panels.html/feed 0 http://btburnett.com/2008/03/using-updatepanels-inside-a-repeater-on-a-content-page.html http://btburnett.com/2008/03/using-updatepanels-inside-a-repeater-on-a-content-page.html#comments Thu, 27 Mar 2008 17:46:00 +0000 Brant Burnett http://www.btburnett.com/?p=6 In my previous post, I described how to use an UpdatePanel that is located inside a Repeater or other data-bound control while maintaining your databinding. In addition to the data-binding challenge, dynamically creating UpdatePanels your page can also pose other complications.

Another issue that I’ve encountered is identifying controls that the AsyncPostBackTrigger on the UpdatePanel refer to if you are using master pages. So long as the control you are trying to trigger on is located in the same Content control of the content page, everything works just fine. However, if the UpdatePanel is located in one Content control while the control that triggers the asynchronous postback is in another UpdatePanel, you’ll get an exception when the page is loaded saying that it couldn’t find a control with the ID you specified.

I’ve found various solutions for correcting this problem by dynamically adding the trigger in code, and using the control’s UniqueID to identify it. However, this becomes significantly more complicated when you are dealing with a dynamically added control. The best solution I’ve found so far is to use ScriptManager.RegisterAsyncPostBackControl to register the post back, and manually call Update on each UpdatePanel to perform the update. Below is the code that I’ve found fixes the problem.

Partial Public Class _Default
Inherits System.Web.UI.Page

Dim DateUpdatePanels AS New List(Of UpdatePanel)

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
ScriptManager.GetCurrent(Me).RegisterAsyncPostBackControl(edtDate)
DataBind()
End Sub

Private Sub Repeater_ItemDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.RepeaterItemEventArgs) Handles Repeater.ItemDataBound
Dim pnl As UpdatePanel = e.Item.FindControl(“upnlShowTimes”)
If Not IsNothing(pnl) Then
DateUpdatePanels.Add(pnl)
End If
End Sub

Private Sub edtDate_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles edtDate.TextChanged
For Each pnl As UpdatePanel In DateUpdatePanels
pnl.Update()
Next
End Sub

End Class

Note that if you define your ScriptManager on your content page instead of the master page, you can refer to it directly instead of using ScriptManager.GetCurrent(Me). Also, you must be sure to set UpdateMode to Conditional on each UpdatePanel.