The Biggest and the Bloatedest III

It seems to be the natural progression of things to become so big and so complex that they just become useless.  Then new upstarts that are simple and lean take over, until they become huge and the cycle continues.

At my job, we use custom controls for our website and application.  Custom controls have always been a great thing for developers because they give you extra functionality built in, so you don’t have to code it.  Telerik controls have been leaders in this field.  But recently, there have been changes – breaking changes – in the newer versions.

I had a simple RadTextBox that I added a script to so that it would do a postback when there was 5 numbers in the textbox (a zip code).  Simple and easy:

if (((event.keyCode||event.which)!=9)&&((this.value.length==5)||(this.value.length==0))) setTimeout("pnlUpdate",300)

This suddenly stopped working.  Well, the postback would happen, but the RadTextBox’s value would be blank.  Telerik support suggested I handle the control’s KeyPress event:

function KeyPress(sender, args) {
    var textLength = sender.get_textBoxValue().length;
    if (textLength >= 5) {

This is stupid enough, that I have to use a custom event and custom methods to get and set the value of a textbox, but there was more that needed done.  The event fires on the key press, but the textbox value doesn’t include that key yet, so you have to include it yourself when measuring the length.  But you have to insert the new character in the right position for when you set the RadTextBox value.  Finally, when using the KeyPress event, the RadTextBox’s MaxLength isn’t enforced, so there has to be a check included for that. 

So from the Telerik proposed solution, I ended up with a script like:

function checkZipCode(s, e) {
    var t, l, c

    c = s.get_caretPosition();
    t = s.get_textBoxValue();
    t = t.substring(0, c) + e.get_keyCharacter() + t.substring(c);
    l = t.length;
    if (l > 5) {

    if (l == 5) {

This is totally unacceptable.  And all because Telerik decided to begin managing the control’s state independently, breaking the standard HTML input behavior.  It’s been growing over time that a developer using Telerik controls has to do things “the Telerik way” in order for the controls to work properly.  Where Telerik controls once were written as extensions to existing controls, they have become total replacements, with little resemblance to the original controls they look like.

So, it’s going to be my recommendation to reduce our dependence on Telerik controls.  I doubt we’ll be able to get rid of the RadGrid, which has its own universe of functionality and weirdness, but when DropDownLists  are rendered as <ul> and TextBoxes don’t use the standard Input Value property, there’s something really wrong about that.  It’s garbage like this that makes MVC so appealing.  Put it this way.  If the big argument against WebForms is that it is trying and failing to make a WinForms model work on the web, then Telerik is taking a WebForms app that is acting like a WinForms app and trying to make it act like an AJAX website.  At that point, you might as well not use WebForms.

Comments are closed.