AjaxControlToolkit (ASP.NET/C#) : CascadingDropDown Extender - Part 2

November 3, 2011 by Christoff Truter C#   ASP.NET  

In the previous part of this post we had a quick look at how to use the CascadingDropDown extender, in this part we're going to look at other perhaps more interesting properties but more in particular databinding (something which seems to be a common question about this extender control).

If you ever attempted to use traditional databinding (e.g. binding your DropDownList to a datasource) in conjunction with this extender, you might have noticed your items being overridden, the reason being that the extender takes control of the DropdownList being extended and performs its own databinding.

Note that it performs binding client side (even on initial binding), like seen in the following firebug screenshot:


(would have been nice if initial binding didn't perform client side calls and rather retrieved the state of the DropDownLists as part of the main page request)

So basically we're going to have to leave it up to the extender to perform databinding.

Furthermore if we need to provide a default value (e.g. previously selected values), we can do that by setting the SelectedValue property on the extender, like seen in the following snippet.

<asp:CascadingDropDown ID="cddlCountries" runat="server" TargetControlID="ddlCountry"
    Category="Country" PromptText="- Please Select -" ServicePath="~/Services/Service.asmx"
    ServiceMethod="GetCountries" SelectedValue='<%# Eval("CountryId") %>' LoadingText="Please wait">
</asp:CascadingDropDown>

<asp:CascadingDropDown ID="cddlProvinces" runat="server" TargetControlID="ddlProvince"
    ParentControlID="ddlCountry" Category="Province" PromptText="- Please Select -"
    ServicePath="~/Services/Service.asmx" ServiceMethod="GetProvinces" SelectedValue='<%# Eval("ProvinceId") %>' LoadingText="Please wait">
</asp:CascadingDropDown>

<asp:CascadingDropDown ID="cddlCities" runat="server" TargetControlID="ddlCity" ParentControlID="ddlProvince"
    Category="City" PromptText="- Please Select -" ServicePath="~/Services/Service.asmx"
    ServiceMethod="GetCities" SelectedValue='<%# Eval("CityId") %>' LoadingText="Please wait">
</asp:CascadingDropDown>

One important thing to note is that the physical placement of the CascadingDropDown extenders in your markup is important, if you swapped your CascadingDropDown nodes around (cddlCountries with cddlCities) your SelectedValue won't be set, this is thanks to the way the JavaScript gets generated for this extension.

So I would suggest that you place your nodes in order of the cascade relation - starting with the top most parent.

Before I realised this small little detail, I made use of contextkeys (enables us to send through additional values) like seen in the following markup:

<asp:CascadingDropDown ID="cddlCities" runat="server" TargetControlID="ddlCity" ParentControlID="ddlProvince"
    Category="City" PromptText="- Please Select -" ServicePath="~/Services/Service2.asmx"
    ServiceMethod="GetCities" UseContextKey="true" ContextKey='<%# Eval("CityId") %>'">

Which calls a webmethod that looks something like this.

[WebMethod]
public CascadingDropDownNameValue[] GetCities(
  string knownCategoryValues,
  string category, string contextKey)
{
    StringDictionary values = CascadingDropDown.ParseKnownCategoryValuesString(knownCategoryValues);
    Int32 ProvinceId = Convert.ToInt32(values["Province"]);
    return City.Get(ProvinceId).Select(p =>
        new CascadingDropDownNameValue(p.Title, p.CityId.ToString(), 
            p.CityId == Convert.ToInt32(contextKey))
    ).ToArray();
}

Which brings me to the small concern I mentioned in the previous part of this post, well... its actually more of a general concern when working with Ajax, observe the following image.



There are a number of things that could have gone wrong in the preceding image causing the error 500, some we can/must catch & handle server side before they even reach the browser, but what about those we can't, or deliberate (for some dark reason) ones?

Unfortunately the creator of this extender didn't provide default functionality to handle these errors, would have been nice if they followed the whole success/failed callback "methodology" that we see when using PageMethods, instead of simply populating the DropDownList with an error 500 message.

I did however manage to create a small little workaround by means of the WebRequestManager, which I hope someone that wants more control over their requests might find useful, observe the following snippet:

function pageLoad() {
    Sys.Net.WebRequestManager.add_completedRequest(On_completedRequest);
}

function On_completedRequest(sender, eventArgs) {
    var url = sender.get_webRequest().get_url();
    if ((sender.get_statusCode() == 500) && (url == 'Services/Service.asmx/GetCities')) {
        alert(sender.get_statusText());
    }
}

Basically I provided a callback (attach event) which will be called when our ajax requests completes and within our handler/callback function we can determine if a request failed (error 500 in this case) and which url caused the failure (url gives us a clue of where we are in the process) then handle it appropriately from there.

Now there is another "non-error" scenario that we can also manage like this, imagine the service used for populating the cascade gets delayed for some reason (e.g. network traffic, database performance), setting the LoadingText for the cascade won't be enough to prevent the user from posting the form.

In order to prevent the user from submitting dodgy data, the basic idea is to disable the submit button (by default), with "please wait" text as button text and as soon as the appropriate request completes we enable the button again (inside our On_completedRequest callback).

All in all I don't think this is a bad extender, we've successfully used it in a few of our projects despite a few small little glitches, but nothing that can't be sorted out.