Core setup / functionalities of kendo UI, and why it breaks things

Hi guys,

I've had numerous discussions with the folks at Telerik, and even though I really do love the look and feel of kendo UI, I have some serious concerns with the usability of the framework, and how it forces us into things we shouldn't be doing.

I just opened a ticket with them again to bring up the topic again, but would like to post it here as well, just to see what the community thinks about this: maybe you guys have solutions?  Or maybe you feel that Telerik should try and reconsider some of their decisions?

Please post to this topic - I'd be very happy to read what others think about my concerns.

This is a copy of the ticket:

---

... I'm still convinced that you have something seriously wrong in your framework.
I'm trying my best to work with the framework, but some of the choices you made, simply took away functionality of jQuery, especially when it comes to extensibilty and chaining.

Let me give you another example, in an effort so you can understand the types of issues we run into with you.

Screenshot: http://awesomescreenshot.com/06awicub9
What you see here, is how all of our "objects" (parties, domain names, countries, whatever object you can imagine: EVERYTHING is object ;-) ) are being displayed; you'll see that there are tabs at the top.

The tabs being displayed here are coming from meta data (for a party, we want to display his general details, have a tab where we can manage his privileges, relations with external software, balances, notes, technical info, SEO information, and a tab containing audit trail of changes to the object).

All these tabs are initiated through meta data which holds the tab name, and the method to call on the server.  This means, that each tab is remotely fetching his data from the server.

So, when I click the "privileges" tab on that page, it actually LOADS the page that he needs to display:
Screenshot: http://awesomescreenshot.com/0c1widi92

As you can see, the HTML being loaded contains other widgets.

Let's see how the combobox is being initialised...

When we send the privileges tab html back to the browser, we're actually only sending the following bit of HTML back to the client:

Now, how does that "magically" change into a kendoCombobox widget?
Well - we want to keep our footprint as low as possible.  So, when the page is being loaded, we have one major javascript file which is minimised, and which uses a jQuery pluging called "livequery".  You can read more about this plugin at http://docs.jquery.com/Plugins/livequery, but to summarise, it allows us to define how new elements need to be treated when they are created in the dom.  By created, you must read: ALL elements that exist in the dom when the code is being called, but also all elements that are being added to the DOM, by an ajax call as in our example for instance, and that fit the criteria.

This is the bit of code that we have in place for a comboboxwidget now:


In short, this tells the livequery plugin to select all items that have the class "fx-widget-relatedobject", and turn it into a kendoUI combobox.

This works like a charm to be honest :-)

Now here is the problem we run into.
Go back to the screenshot at http://awesomescreenshot.com/0c1widi92.

As you will understand from the screenshot: that first combo, we want to listen to the "change" event, so that when that change event is being triggered, we can retrieve the methods for the selected class, and display them at the bottom left part of the screen.

When we used to use jQueryUI for instance, this was really easy.  An input element converted into a jQueryUI combobox for instance, would still trigger the change() event of the underlying input element.  You - for reasons I still, after so many discussions, do not understand, have chosen not to do this.

The added javascript code that we need for this tab contents, is being sent back together with the HTML, but in stead of doing this:

we needed to find another way to add this to the element.

The major problem I'm having here is that for this particular bit of code, I feel that I should not know that this is an element that will be converted into a kendoui combobox, so I want to avoid the use of 
at this point.  Unfortunately, you're forcing me into this anyway, so I am breaking my MVC here (this is business logic, and I don't want to need to care about what widget this will finally be converted into...)

Secondly, and this is even more difficult: I do not know - when my added javascript is being executed - whether the input element has already been converted into the kendocombobox.  So if my code is being executed before the livequery plugin executes the initialisation of the kendoComboBox,  $("#privileges_class").data("kendoComboBox"); will in fact return undefined.

So, I had to come up with a solution, and I have a very dirty one.

In my livequery plugin, I have added a tiny bit of code to trigger a custom event ("fx_init") (you can see that above).  Meaning that whenever an input is converted into a kendoui combobox, this event is being triggered.

My added javascript being returned by the ajax call, has been updated to do this:

What I do here, is listen to the fx_init event which is being triggered by the livequery plugin, and immediately call it myself as well.  We need this, as we can not predict whether the livequery code gets executed before this bit of code or vice versa.  To ensure we don't execute the code twice, we save a boolean on the element to make sure we evaluate that te event listener already exists...

I'm not saying that your widgets are bad, but I sincerely hope that with this example I can illustrate you once more that even though you might have had your reasons, you're forcing us to increase our codebase, and our footprint, which makes coding a lot more difficult.

Add to the fact that I'm losing my strict MVC pattern (by requiring me to know that this is a kendoComboBox in my business javascript logic...), I feel that your framework may not be what we need.

I've had many discussions on the topic, and unfortunately, most of the time, I have been blocked by you guys.  I'm used better from Telerik to be honest, so I hope that this time someone may actually see my point,and understand why it is so important to be compatible with jQuery, and follow the proper jQuery extension / plugin authoring guidelines, because if you don't, you are in fact increasing our codebase, and we really want to avoid this at all times.