Albert Shenker
Top achievements
Rank 1
Veteran
Iron
Rank 1
Veteran
Iron
Albert Shenker
asked on 30 Jul 2009, 04:27 PM
Despite the thread title, this is not meant to be a bash of Telerik. When it comes to AJAX, i believe their controls are second to none. However, there are a couple instances where I believe they can imporve. This all has to do with the use of their controls in medium trust environments. Now, I am not a network admin, nor do I know a great deal about webserver setup, so I am coming to this as a novice. However, I do know that the vast majority of third party hosts use medium trust in their environments, and it is even becoming more prevelant to use this in dedicated server systems. So I think it is a huge problem, and only getting bigger.
My understanding of the issue is that lmitations in MS AJAX itself (the framework upon which Rad Ajax is built) produce the problems. Ok, that is certainly credible. However, it is very dfficult to find info on this on the Terlik site. On the "changes and backward compatibility" section of the Ajax help files, there is a small section that deals with this titled "Full DNN support". If you don't use DNN, I don't know why this would ever catch your eye. Also, this is not just a DNN issue. It effects all sorts of functionality. Telerik has two recommended approaches to avoid these issues in medium trust environments. The first is to set the AjaxManager RestoreOriginalRenderDelegate property to False. The second is to inherit your page from RadAjaxPage instead of the ASP.NET Page class. I will have more comments on these solutions below....
In my case I was introduced to this problem when I was trying to dynamically load usercontrols (with Ajax) that had javascript on them. I, and I am sure lots of other people, have spent a great deal of time trying to figure out why this doesn't work, as was described in this forum thread:
http://www.telerik.com/community/forums/aspnet-ajax/ajax/radajax-manager-does-not-load-js-files-in-dynamically-loaded-user-control.aspx
there is also a blog relating to this issue, though the blogger doesn't seem to be responsive to comments.
http://blogs.telerik.com/tervelpeykov/posts/08-10-20/AJAX_Using_AJAX_to_load_a_usercontrol_that_has_JavaScript_declared_in_it.aspx
Anyhow, I was once again reintroduced to the Ajax limitations when trying to implement Telerik's ToolTipified grid example. I thought I was doing everyhting they were, but I just couldn't get the example to work properly. As it turns out, setting the AjaxManager RestoreOriginalRenderDelegate property to false did not allow the example to work properly. I haven't tested it out, but I bet a great deal of telerik's examples having to do with ajax don't work properly when this ajaxmanager property is set. So, in my opinion, this is not a particularly good solution to working in medium trust environments, if much of the functionality is limited or lost. And, as for inheriting from RadAjaxPage, I have not seen if that works perfectly, but it simply isn't an option in the majority of project I work on, becasue most of the projects I develop inherit from some other custom base class (not Page).
So, I have one suggestion and two questions regarding all fo this..
Suggestion: Please document these issues better. I'm sure its not a great sales practice to admit your product has problems in a widespread environment, however, I think people will be much happier if they save themselves some time instead of spending countless hours debugging their code when the issue was so easy to diagnose. I know I would have. Every one of your Ajax-related examples should have a note that they may not function properly if the AjaxManager RestoreOriginalRenderDelegate property is set to false (as you require to work in medium trust environments).
Quesiton 1: As I stated before, I accept that this whole issue stems from limitations in the MS Ajax framework, and asside from the documentation of it, I don't have a beef with what Telerik has done regarding the controls. However, given the large-scale reach of these limitations and their effect on so many projects, is Telerik investigating implementing their own work-arounds? If you can get to a point where your own examples work in medium trust environments without doing something as drastic as inheriting from a Telerik base classs, I think that would be sufficient.
Question 2: Does Telerik have any knowledge of Microsoft working on improving these limitations?
My understanding of the issue is that lmitations in MS AJAX itself (the framework upon which Rad Ajax is built) produce the problems. Ok, that is certainly credible. However, it is very dfficult to find info on this on the Terlik site. On the "changes and backward compatibility" section of the Ajax help files, there is a small section that deals with this titled "Full DNN support". If you don't use DNN, I don't know why this would ever catch your eye. Also, this is not just a DNN issue. It effects all sorts of functionality. Telerik has two recommended approaches to avoid these issues in medium trust environments. The first is to set the AjaxManager RestoreOriginalRenderDelegate property to False. The second is to inherit your page from RadAjaxPage instead of the ASP.NET Page class. I will have more comments on these solutions below....
In my case I was introduced to this problem when I was trying to dynamically load usercontrols (with Ajax) that had javascript on them. I, and I am sure lots of other people, have spent a great deal of time trying to figure out why this doesn't work, as was described in this forum thread:
http://www.telerik.com/community/forums/aspnet-ajax/ajax/radajax-manager-does-not-load-js-files-in-dynamically-loaded-user-control.aspx
there is also a blog relating to this issue, though the blogger doesn't seem to be responsive to comments.
http://blogs.telerik.com/tervelpeykov/posts/08-10-20/AJAX_Using_AJAX_to_load_a_usercontrol_that_has_JavaScript_declared_in_it.aspx
Anyhow, I was once again reintroduced to the Ajax limitations when trying to implement Telerik's ToolTipified grid example. I thought I was doing everyhting they were, but I just couldn't get the example to work properly. As it turns out, setting the AjaxManager RestoreOriginalRenderDelegate property to false did not allow the example to work properly. I haven't tested it out, but I bet a great deal of telerik's examples having to do with ajax don't work properly when this ajaxmanager property is set. So, in my opinion, this is not a particularly good solution to working in medium trust environments, if much of the functionality is limited or lost. And, as for inheriting from RadAjaxPage, I have not seen if that works perfectly, but it simply isn't an option in the majority of project I work on, becasue most of the projects I develop inherit from some other custom base class (not Page).
So, I have one suggestion and two questions regarding all fo this..
Suggestion: Please document these issues better. I'm sure its not a great sales practice to admit your product has problems in a widespread environment, however, I think people will be much happier if they save themselves some time instead of spending countless hours debugging their code when the issue was so easy to diagnose. I know I would have. Every one of your Ajax-related examples should have a note that they may not function properly if the AjaxManager RestoreOriginalRenderDelegate property is set to false (as you require to work in medium trust environments).
Quesiton 1: As I stated before, I accept that this whole issue stems from limitations in the MS Ajax framework, and asside from the documentation of it, I don't have a beef with what Telerik has done regarding the controls. However, given the large-scale reach of these limitations and their effect on so many projects, is Telerik investigating implementing their own work-arounds? If you can get to a point where your own examples work in medium trust environments without doing something as drastic as inheriting from a Telerik base classs, I think that would be sufficient.
Question 2: Does Telerik have any knowledge of Microsoft working on improving these limitations?
3 Answers, 1 is accepted
0
Hi Albert,
As you may know in order RadAjax to work it needs to hook to rendering logic. However the only suitable extensibility point for this is by replacing the Page's RenderMethod delegate. Unfortunately the Page class does not expose this as an event but provides a method which sets the new delegate and removes the previous one, making it impossible to restore it as the original value is not publicly accessible.
In order to cope with this RadAjax uses reflection in order to get the original delegate from a page's private field and to restore it. Thus when current context does not have reflection permissions this is not possible and the use of RadAjaxPage is needed. This class is actually same as regular page but exposes the render delegate for the RadAjax.
As we constantly try to improve our products and to make developers' life easier, we were aware that subclassing the RadAjaxPage is not always an option, thus we introduced the
RestoreOriginalRenderDelegate property which, as been a "hack" in a way, indeed may not be applicable in all situation but can be used in a pretty straight-forward manner.
In this line of thoughts we will be more than happy to hear any concrete suggestions from your side on how to optimize and improve the depicted functionality.
Regarding the described scenario concerning loading of scripts which placed into dynamically loaded usercontrols: As far as I'm aware of MS' update panels, they do not support such type of functionality and this feature is unique to RadAjax.
Best wishes,
Rosen
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
As you may know in order RadAjax to work it needs to hook to rendering logic. However the only suitable extensibility point for this is by replacing the Page's RenderMethod delegate. Unfortunately the Page class does not expose this as an event but provides a method which sets the new delegate and removes the previous one, making it impossible to restore it as the original value is not publicly accessible.
In order to cope with this RadAjax uses reflection in order to get the original delegate from a page's private field and to restore it. Thus when current context does not have reflection permissions this is not possible and the use of RadAjaxPage is needed. This class is actually same as regular page but exposes the render delegate for the RadAjax.
As we constantly try to improve our products and to make developers' life easier, we were aware that subclassing the RadAjaxPage is not always an option, thus we introduced the
RestoreOriginalRenderDelegate property which, as been a "hack" in a way, indeed may not be applicable in all situation but can be used in a pretty straight-forward manner.
In this line of thoughts we will be more than happy to hear any concrete suggestions from your side on how to optimize and improve the depicted functionality.
Regarding the described scenario concerning loading of scripts which placed into dynamically loaded usercontrols: As far as I'm aware of MS' update panels, they do not support such type of functionality and this feature is unique to RadAjax.
Best wishes,
Rosen
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Albert Shenker
Top achievements
Rank 1
Veteran
Iron
Rank 1
Veteran
Iron
answered on 31 Jul 2009, 02:24 PM
Thanks for the info, but this is all stuff I have already gleaned from my numerous communications with Telerik regarding these issues. Like I said, I realize the problem is not one of Telerik's making. However, there's at least one thing Telerik should do regarding this matter. It should document it better. Like I said, as of today, the "hacK" you came up with makes it so many of your Ajax examples don't work properly in medium trust environments. So, rather than spending hours trying to figure out why one of your examples doesn't work verbatim in one environment or another, it would be much better if you stated somewhere clearly that these examples may not function properly if the user has to set RestoreOriginalRenderDelegate property to false (in order to be able to be in a medium trust environment). This info shouldn't be buried in one cryptic paragraph on the changes and backwards compatibility page.
The same goes for things like dynamic loading of user controls with javascript. I appreciate that you came up with a way of doing this that is not supported out of the box by MS update panels. That is why you guys are good at what you do. But your solution doesn't work in medium-trust environments, and this isn't stated anywhere.
I have been using your Ajax controls from the begining. Now, if I encounter a problem, I know to check and see if it is the medium-trust issue first and most of the time it is. However, this knowledge was gained from many, many hours of tearing my hair out. I don't see any downside to you documenting things to avert this sort of frustration for other developers.
Lastly, since you are MIcrosoft partners now, is there any communication between the two of you regarding this medium-trust problem. Perhaps the solution needs to come from their end (Asp.Net 4.0?), but given that Ajax is becoming more and more ingrained as far as web applications are concerned, and medium trust is becoming more and more engrained as far as server configuration is concerned, I fail to see how addressing these issues in not a high a priority.
The same goes for things like dynamic loading of user controls with javascript. I appreciate that you came up with a way of doing this that is not supported out of the box by MS update panels. That is why you guys are good at what you do. But your solution doesn't work in medium-trust environments, and this isn't stated anywhere.
I have been using your Ajax controls from the begining. Now, if I encounter a problem, I know to check and see if it is the medium-trust issue first and most of the time it is. However, this knowledge was gained from many, many hours of tearing my hair out. I don't see any downside to you documenting things to avert this sort of frustration for other developers.
Lastly, since you are MIcrosoft partners now, is there any communication between the two of you regarding this medium-trust problem. Perhaps the solution needs to come from their end (Asp.Net 4.0?), but given that Ajax is becoming more and more ingrained as far as web applications are concerned, and medium trust is becoming more and more engrained as far as server configuration is concerned, I fail to see how addressing these issues in not a high a priority.
0
Hello Albert,
Thank you for the feedback - I see your point here and agree that the statement about the RestoreOriginalRenderDelegate property or RadAjaxPage inheritance you requested should be included in the RadAjax support resources.
I spoke with our help team on this subject and they confirmed that this detail will be documented under the 'Currently unsupported scenarios' -> 'Current RadAjax Limitations' topic from the online documentation. Thus it will be more 'visible' for the developers who would like to choose this path in order to be aware of the obstacles they may encounter.
Regarding the communication with the MS team on this subject:
We hope that we will see improvements in this area with the ASP.NET 4.0 version of the framework although we have not received a definite confirmation that this will happen.
Kind regards,
Sebastian
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Thank you for the feedback - I see your point here and agree that the statement about the RestoreOriginalRenderDelegate property or RadAjaxPage inheritance you requested should be included in the RadAjax support resources.
I spoke with our help team on this subject and they confirmed that this detail will be documented under the 'Currently unsupported scenarios' -> 'Current RadAjax Limitations' topic from the online documentation. Thus it will be more 'visible' for the developers who would like to choose this path in order to be aware of the obstacles they may encounter.
Regarding the communication with the MS team on this subject:
We hope that we will see improvements in this area with the ASP.NET 4.0 version of the framework although we have not received a definite confirmation that this will happen.
Kind regards,
Sebastian
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.