[Solved] RadTreeNode.Category dropped

[Michael Hanson]

Why on earth have you dropped support for the Category attribute of the RadTreeNode.  I have three web applications that rely heavily on this attribute to quickly identify which Category a node appears in.  The nodes can appear in multiple places in the tree and the Category attribute is perfect for identifying where it is.

You promised all Prometheus controls would be backward compatible with their predecessors!!!!  So many things have changed on this control I would have to make major changes to my applications to use the Prometheus TreeView control.

[Shane]

I have to agree with Michael.

We need Category!!!

:)

Shane

[Nikolay]

Hi Shane,

The purpose of the RadTreeView Prometheus edition was to make it compatible with MS Ajax. Therefore, we entirely built the control on top of MS Ajax. This, however, required some changes that could not be omitted.

As for the Category property - we decided that using custom attributes should successfully replace the usage of the Category property. Also, we believe that using custom attributes is a more common approach.

Regards,
Nick
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Michael Hanson]

Going for custom attributes is ok in principle, but Category is such a fundamental one that you can pretty much guarantee many developers have used it already and therefore migrating code requires major changes, and therefore a major impediment to complete migration to Prometheus.

I tried changing to a custom attribute of Category but it did not work, I was not able to reference it on the server side, so I have gone back to the orginal code and will not be migrating this application to Prometheus.

Interestingly the documentation for the Prometheus Tree View still shows the Category property suggesting it should still be there.

The 6 licences for my company are up for renewal this month, but I won't be renewing, in my view Telerik have completely failed in several areas to live up to the promise of backward compatibility moving from RadControls to Prometheus. 

[Shane]

Hi Michael,

I have to disagree with you on this.

I think the attribute is much powerful that Category, because you can have any custom attribute you like. You only need to change few things.

If you are assigning Category in codebehind then you just need to do node.attributes.add("Category",value). And if you access this value in javascript then

var node = args.get_node();
        var Category = node.get_attributes().getAttribute("Category");

will do.

from codehind you can access an attribute

Dim category As String = node.Attributes.Item("Category").ToString()

But there is a bug when you load-on-demand. If you load the nodes in load-on-demand, you will get a javascript error which says "Too many recursion". Hopefully telerik will fix this sooner

Cheers,
Shane

[Warren]

Michael,

Three things.  First --
Don't be so fatalistic.  It's unprofessional.
If you aren't going to renew your Telerik subscriptions because their new beta software doesn't support 100% of everything that their production versions do (yet), you're over-reacting.  If anything, you should be filing suggestions for improvements so that when Prometheus comes out of beta, it will meet your needs.  Let me be a bit more forceful with this point: it's still beta software.  If you are choosing to implement Prometheus now, it's implicit that you are in effect agreeing to help test the software and report problems as you find them.

Telerik could, for example, re-add the Category property in a service pack and simply have it use the custom attribute plumbing, to ease the transition.  You can also create your own derived class from Telerik.Web.UI.RadTreeView and add whatever methods and properties you require for your application.  We've been doing this for a long time to add in searching the tree for nodes based on specific filter conditions.


Second thing --
Telerik has never promised full backwards compatibility. They said they'd try their best but that there were no guarantees.  See this:
http://www.telerik.com/help/radcontrols/prometheus/FAQ.html


Third thing --
RadTreeView classic works just fine in a Prometheus application.  Migrating to Promethus isn't an all-or-nothing proposition.  Stick with RadTreeView classic (but upgrade to 2007 Q3) and you won't have any problems.  Your complaining is for naught -- Telerik's got you covered.

[Michael Hanson]

Shane

I wasn't suggesting there was anything wrong with the approach of the Attributes collection, I agree it is a good idea and I frequently use the Attributes collection of standard controls.  What I was suggesting was that the Category property is such a fundamental one that it deserves to be a Property on it's own.  Providing custom attributes capability is a great extensibility mechanism, but when an attribute is likely to be used frequently it deserves first class status.

I had already tried your suggested code and it works fine when you are accessing the attribute on the client side, but I was trying to migrate a page that used the property server side and the custom attribute was not available server side after setting it dynamically.  So it doesn't work for me, hence my point about having to do a major re-write of code to use Prometheus.

[Michael Hanson]

First thing:

You insult is dully noted and ignored, I don't know you so shy should I care what you think.

Second thing:

Accepted

Third thing:

I am trying to follow the advice of Telerik who have stated on more than one occasion that we should be using Prometheus for all future development.  I was making some major changes to a page that included the TreeView so it made sense to try to move it across.


As a customer it is my choice whether I renew my licences or not, if I am not satisfied with the support I get then I can choose not to continue paying the supplier money.

IMHO the point of using third party controls is to avoid the need for creating custom controls, if I have to derive from theirs to get the behaviour I want I might as well create my own that does exactly what I want and leave out the additional functionality and complexity that comes with it.

[Atanas Korchev]

Hi guys,

Thanks for the feedback. We would bring back the Category property for service pack release of RadTreeView (as well as fix all reported issues). Initially we thought that custom attributes supersede the Category property. However having the Category property back would facilitate migration from RadTreeView "Classic" to RadTreeView "Prometheus". Thanks for bringing this up!

By the way if you have found any problems with the "Prometheus" RadTreeView - please let us know.

Regards,
Atanas Korchev,
the Telerik dev team

Instantly find answers to your questions at the new Telerik Support Center

[Warren]

Michael,

Your lack of professionalism is getting in the way of whatever point it is you're trying to make.  We aren't children here -- we don't stamp our feet and threaten to take our ball and go home if we don't get exactly what we want.

Calm down, and give it some rational and logical thought.  It can't possibly hurt.  Oh, and, ignoring me won't make the reality of what I'm telling you disappear.


If you'd like to try your hand at writing a complete replacement for RadTreeView that has as complete a programming and skinning model, with semantically correct HTML and cross-browser compatibility, you can choose to do so, of course. You'll probably find that it will cost you significantly more time, effort, and money to accomplish this than if you continue to use RadTreeView.  You'd be doing the people who pay you a major disservice.  Extending RadTreeView to add properties or methods is, by comparison, pretty easy... it should take any reasonably skilled developer less than an hour.

Or, of course, you could just do a search & replace of ".Category" with ".Attributes["Category"]", which is what we did... took about 30 seconds and it worked perfectly the first time.  I really don't understand how this could be so difficult.

[Michael Hanson]

I would have thought we also didn't go around telling other people how to behave.