Assume a usercontrol has a manager proxy. In one case I'll use the UC on a content page under a master page, and in another case I'll use the UC on a standalone page. I want it to behave the same regardless of the container.
My basic question is, how do we ensure that the Proxy is wired to the container Manager regardless of what the container is?
When we use mgr=RadAjaxManager.GetCurrent(this.Page) , it returns a Manager, but the UC is coded to operate on it's local Proxy.
If RadControls "automatically" wires a Manager to all nested proxies, does this happen in the Render event? I just want to make sure that when I manipulate the proxy in Load or PreRender for example, that the settings are respected by the top-level manager wherever it happens to be. If this requires the UC to selectively get a handle to the Manager or the Proxy, depending on who the container is, so be it. I just need to know the rules.
In a more complex example, what if a usercontrol is nested in another UC? I would hope that the lowest-level proxy can manage it's own controls rather than having to get a reference to the container proxy so that it can wire itself up. This brings up two more questions:
If a UC is in a UC, does the nested UC need to be in a panel?
Does the container need to set a trigger for the child UC to trigger itself?
All of the docs/examples on this topic use the most basic scenarios. I've never seen anything complex or covering numerous scenarios in the same project. Is there complete flow documentation somewhere, even some internal doc at Telerik, a spec or something that Support people use to remind themselves how the product should be behaving? I think a doc like this will help everyone with questions about this to easily understand the expected behavior. I'm not looking for handouts of code samples, just a reference to complete documentation would be enough.
TIA
My basic question is, how do we ensure that the Proxy is wired to the container Manager regardless of what the container is?
When we use mgr=RadAjaxManager.GetCurrent(this.Page) , it returns a Manager, but the UC is coded to operate on it's local Proxy.
If RadControls "automatically" wires a Manager to all nested proxies, does this happen in the Render event? I just want to make sure that when I manipulate the proxy in Load or PreRender for example, that the settings are respected by the top-level manager wherever it happens to be. If this requires the UC to selectively get a handle to the Manager or the Proxy, depending on who the container is, so be it. I just need to know the rules.
In a more complex example, what if a usercontrol is nested in another UC? I would hope that the lowest-level proxy can manage it's own controls rather than having to get a reference to the container proxy so that it can wire itself up. This brings up two more questions:
If a UC is in a UC, does the nested UC need to be in a panel?
Does the container need to set a trigger for the child UC to trigger itself?
All of the docs/examples on this topic use the most basic scenarios. I've never seen anything complex or covering numerous scenarios in the same project. Is there complete flow documentation somewhere, even some internal doc at Telerik, a spec or something that Support people use to remind themselves how the product should be behaving? I think a doc like this will help everyone with questions about this to easily understand the expected behavior. I'm not looking for handouts of code samples, just a reference to complete documentation would be enough.
TIA
5 Answers, 1 is accepted
0
Hello TonyG,
Note that RadAjaxManagerProxy copies the exact same RadAjaxManager designer configuration so that you can set all the necessary AJAX settings within the WebUserControl/ContentPage entirely through the designer or declaratively.
When you are using RadAjaxMangerProxy to configure the ajax settings, only thing you should care is that the page has RadAjaxManager control, be it on the Master or some Content Page. From then on it does not matter how deeply nested is the UC with the Proxy.
In case you need to add ajax setting programatically in the UC, I suggest that you do it through the main manager instance instead of using the AjaxManagerProxy. You can get the instance by calling RadAjaxManager.GetCurrent(Page) and then follow the instructions here.
Indeed, most of the example are kept simple so it is easier to understand how our controls work and can be used. More complex scenarios are shown only for the cases a control would behave or should be used differently is a specific situation, otherwise you could use it same way in a simple or a complex setup.
Additionally, you can find more sample with specific scenario implementation in our Code Library and Knowledge Base sections.
I hope this helps.
Regards,
Iana
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.
Note that RadAjaxManagerProxy copies the exact same RadAjaxManager designer configuration so that you can set all the necessary AJAX settings within the WebUserControl/ContentPage entirely through the designer or declaratively.
When you are using RadAjaxMangerProxy to configure the ajax settings, only thing you should care is that the page has RadAjaxManager control, be it on the Master or some Content Page. From then on it does not matter how deeply nested is the UC with the Proxy.
In case you need to add ajax setting programatically in the UC, I suggest that you do it through the main manager instance instead of using the AjaxManagerProxy. You can get the instance by calling RadAjaxManager.GetCurrent(Page) and then follow the instructions here.
Indeed, most of the example are kept simple so it is easier to understand how our controls work and can be used. More complex scenarios are shown only for the cases a control would behave or should be used differently is a specific situation, otherwise you could use it same way in a simple or a complex setup.
Additionally, you can find more sample with specific scenario implementation in our Code Library and Knowledge Base sections.
I hope this helps.
Regards,
Iana
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
TonyG
Top achievements
Rank 1
Rank 1
answered on 12 May 2009, 03:37 PM
We might be able to get all of my questions on this topic answered here, thanks. :)
I've been assuming that each proxy handles what's under it but it seems the top page-level manager handles ajaxification of all controls. That makes sense but makes me wonder about "over burdening" the manager with event management details for every control, and the performance penalty of refreshing that information every time a control is added to the page or removed. It would really help to see some diagram or blog explanation of exactly what's happening when we wire these controls so that we have a better intuitive understanding of exactly how to use them - note the never ending stream of questions on this topic from our colleagues about events not firing, double firing, when to use the proxy, etc.
If the general rule is to use RadAjaxManager.GetCurrent(Page), then why bother with a RadAjaxManagerProxy anywhere? It gets confusing whether sub-components need an extra control, like it seems every content page and user control needs a form decorator too, but we must have only one ajax manager and script manager for the entire control tree.
Assume the following in a user control:
RadAjaxManager mgr = RadAjaxManager.GetCurrent(Page);
mgr.AddAjaxSetting(source,target);
If we then unload the control, do we need to remove all of the wiring for it from the manager as well? I've been assuming that when we go through a postback that PreRender for all controls in the entire chain should re-wire themselves from scratch. (No state is maintained between postbacks.) In other words, does it hurt to set a source/target more than once, or to have the manager set for controls that no longer exist?
Finally, under what circumstances must we have a panel wrapped around a control in order to ajaxify it, compared to just ajaxifying the control directly?
Thank you kindly.
I've been assuming that each proxy handles what's under it but it seems the top page-level manager handles ajaxification of all controls. That makes sense but makes me wonder about "over burdening" the manager with event management details for every control, and the performance penalty of refreshing that information every time a control is added to the page or removed. It would really help to see some diagram or blog explanation of exactly what's happening when we wire these controls so that we have a better intuitive understanding of exactly how to use them - note the never ending stream of questions on this topic from our colleagues about events not firing, double firing, when to use the proxy, etc.
If the general rule is to use RadAjaxManager.GetCurrent(Page), then why bother with a RadAjaxManagerProxy anywhere? It gets confusing whether sub-components need an extra control, like it seems every content page and user control needs a form decorator too, but we must have only one ajax manager and script manager for the entire control tree.
Assume the following in a user control:
RadAjaxManager mgr = RadAjaxManager.GetCurrent(Page);
mgr.AddAjaxSetting(source,target);
If we then unload the control, do we need to remove all of the wiring for it from the manager as well? I've been assuming that when we go through a postback that PreRender for all controls in the entire chain should re-wire themselves from scratch. (No state is maintained between postbacks.) In other words, does it hurt to set a source/target more than once, or to have the manager set for controls that no longer exist?
Finally, under what circumstances must we have a panel wrapped around a control in order to ajaxify it, compared to just ajaxifying the control directly?
Thank you kindly.
0
Hi TonyG,
RadAjax for ASP.NET AJAX is built on top of MS AJAX Framework and follows the same logic of a regular ASP:UpdatePanel. It turns the regular postbacks into callbacks, e.g. when a control set as ajax initiator in the ajax settings makes postback, this is being turn into postback and the request finishes only these controls set as updated controls are rendered on the page.
Having an RadAjaxManagerProxy control could be thought as if you have RadAjaxManager when working with the VS designer. When you need to do something in code, just access the instance of the main RadAjaxManager for your purpose. Additionally, it is not obligatory to use RadAjaxManagerProxy, it is only if you want to set ajax settings declaratively in your user control.
Indeed, when adding ajax manager settings dynamically, you need to make sure the controls taking part in the ajax pair are available on the page. However, if these settings are in the dynamically loaded user control, they will be added to the RadAjaxManager settings collection only when the user controls is loaded and not when it is not.
A Panel should be placed around a control and ajaxified instead of it respectively if the control visibility status changes, e.g. the control is or might become invisible. Also a Panel should wrap a Repeater and in some cases a RadioButtonList. Other controls and cases exceptions are not known.
Let me know if I missed answering any of your questions and if something is left unclear.
All the best,
Iana
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.
RadAjax for ASP.NET AJAX is built on top of MS AJAX Framework and follows the same logic of a regular ASP:UpdatePanel. It turns the regular postbacks into callbacks, e.g. when a control set as ajax initiator in the ajax settings makes postback, this is being turn into postback and the request finishes only these controls set as updated controls are rendered on the page.
Having an RadAjaxManagerProxy control could be thought as if you have RadAjaxManager when working with the VS designer. When you need to do something in code, just access the instance of the main RadAjaxManager for your purpose. Additionally, it is not obligatory to use RadAjaxManagerProxy, it is only if you want to set ajax settings declaratively in your user control.
Indeed, when adding ajax manager settings dynamically, you need to make sure the controls taking part in the ajax pair are available on the page. However, if these settings are in the dynamically loaded user control, they will be added to the RadAjaxManager settings collection only when the user controls is loaded and not when it is not.
A Panel should be placed around a control and ajaxified instead of it respectively if the control visibility status changes, e.g. the control is or might become invisible. Also a Panel should wrap a Repeater and in some cases a RadioButtonList. Other controls and cases exceptions are not known.
Let me know if I missed answering any of your questions and if something is left unclear.
All the best,
Iana
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
TonyG
Top achievements
Rank 1
Rank 1
answered on 14 May 2009, 01:16 AM
Iana - You're very helpful and patient. I sincerely appreciate your effort here and hope I'm not wasting your time.
Good information: RadAjaxManagerProxy is only for declarative coding, and use/ajaxify a panel for visibility.
Assuming we're not changing visibility, is it necessary to do something like this? :
manager.AddAjaxSettings(panel,panel)
The idea here is that any control on the panel should trigger the refresh of any other control on that panel. Same for
manager.AddAjaxSettings(usercontrol,usercontrol)
Under what circumstances would we have a trigger where the source and target are the same? In some cases I would prefer to just have specific controls in a UC trigger other specific controls, but in my experience that hasn't worked. For many cases it's fine/preferred to have any control on a panel trigger the entire panel - but do we need to wire every control to the panel or to one another? Right now I ajaxify containers like panels and usercontrols to trigger themselves, I get controls to trigger their containers, and controls to trigger other controls within containers. Going back to Ajax basics, if we set a container as a trigger then all controls in that container get refreshed on postback. Somehow the RadAjaxManager seems to be more complicated.
Thanks again.
Good information: RadAjaxManagerProxy is only for declarative coding, and use/ajaxify a panel for visibility.
Assuming we're not changing visibility, is it necessary to do something like this? :
manager.AddAjaxSettings(panel,panel)
The idea here is that any control on the panel should trigger the refresh of any other control on that panel. Same for
manager.AddAjaxSettings(usercontrol,usercontrol)
Under what circumstances would we have a trigger where the source and target are the same? In some cases I would prefer to just have specific controls in a UC trigger other specific controls, but in my experience that hasn't worked. For many cases it's fine/preferred to have any control on a panel trigger the entire panel - but do we need to wire every control to the panel or to one another? Right now I ajaxify containers like panels and usercontrols to trigger themselves, I get controls to trigger their containers, and controls to trigger other controls within containers. Going back to Ajax basics, if we set a container as a trigger then all controls in that container get refreshed on postback. Somehow the RadAjaxManager seems to be more complicated.
Thanks again.
0
Hi TonyG,
Usual case where you could have a setting where panel updates itself, is if a control in that panel updates the whole panel, which is it naming container same time. In other words when a control have to update its content container, you'd better ajaxify the whole container. In most of the cases even more controls might have to update their parent container. Then instead of adding setting where each of them updates the Panel for instance, make the Panel updates itself and thus replace multiple settings with one.
Feel free to ask all questions that bother you.
Kind regards,
Iana
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.
Usual case where you could have a setting where panel updates itself, is if a control in that panel updates the whole panel, which is it naming container same time. In other words when a control have to update its content container, you'd better ajaxify the whole container. In most of the cases even more controls might have to update their parent container. Then instead of adding setting where each of them updates the Panel for instance, make the Panel updates itself and thus replace multiple settings with one.
Feel free to ask all questions that bother you.
Kind regards,
Iana
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.