July 2013 ยป Kentico CMS Quick Tip - Use ClientIDMode Appropriately
Jul 31

Kentico CMS Quick Tip - Use ClientIDMode Appropriately

A few of my fellow developers were recently inspired by one of the newer knowledge based articles post over on Kentico DevNet about how to serve less HTML code from a Kentico web part. While their intentions were good they forgot one golden rule of correctly utilizing ASP.NET controls that involve PostBacks. It took me awhile to figure out why none of the Edit and Delete buttons were working as expected on each row of the UniGrid. I am sharing this quick story today to hopefully save some time for other Kentico developers out there.

What they did was follow the article's suggestion to set the ClientIDMode property of the control, in this case the UniGrid control, to Static. Changing this setting does indeed allow for the id of the control to be nicely controllable, and also allow it to render out a clean id. My colleagues did this because they wanted to apply some jQuery code to move an element around in the header row of each column in the grid and change up some style rules dynamically. The change to the property value had the desired effect, and everything worked, well almost everything worked.

Changing the property value like the following example:

 

<cms:UniGrid runat="server" ID="gridElem" ClientIDMode="Static" ... />

 

Resulted in:

 

<table id="gridElem" class="UniGridGrid _nodivs" cellspacing="0" cellpadding="3" ...>

 

Instead of:

 

<table id="m_c_eventList_gridElem" class="UniGridGrid _nodivs" cellspacing="0" cellpadding="3" ...>

 

After that change, the jQuery code worked great, and there was no risk in breaking my #2 thing NOT to do with Kentico CMS.

However, you have to be very careful when applying this optimization technique. Setting the ClientIDMode property to Static on an ASP.NET control that has child controls in its control hierarchy is not recommended. Basically instead of having the ASP.NET framework generate unique control ids for all of the children you are telling it to render every control without worrying about having an absolute unique value.

The real issue came into play when the control was added twice to the page because it was meant to be re-useable web part for a dashboard. The first UniGrid worked perfectly, but the second one nothing worked, no pager, no actions, no nothing.

Since the Edit and Delete buttons on each row are child controls of the UniGrid control the technique indeed did cause everything to break. Basically the default __doPostBack(...) script that the ASP.NET framework generates does not line up with the control ID and therefore clicking the buttons cause nothing to happen at all. It was not fun to track this down. I was cursing more than once at the screen during this debugging session.

Once we removed the ClientIDMode property everything just magically worked again. So the moral of the story is don't go crazy over optimizing if you have don't have to. This is especially true with ASP.NET controls or Kentico CMS Web parts that use one or more PostBacks. For simple labels and panels it is a good technique to use though.

 

You might also be interested in

[X]

Be the first to know about my latest Kentico Tips & Tricks!

Do not show again