MSFT AjaxToolKit: Bizarre DynamicServicePath - well Path Issue AND SOLUTION
In trying to troubleshoot my issues with the migration I noted that for the sample ModalPopUp example with the toolkit automatically populates the DynamicServicePath. I don't declare it explicitly in my ascx file it is auto-generated.
The issue I have is the ToolKit Example if using the quick and easy Master Page Website deal - it is populated with the full path. When you use a .Net application that generates urls dynamically - then it defaults to the root of the website...
Examples:
From the toolkit example (Beta release )
Sys.Application.add_init(function() {
$create(AjaxControlToolkit.ModalPopupBehavior, {"BackgroundCssClass":"modalBackground","CancelControlID":"ctl00_ContentPlaceHolder1_CancelButton","DropShadow":true,"DynamicServicePath":"/test/ModalPopup/ModalPopup.aspx","id":"ctl00_ContentPlaceHolder1_ModalPopupExtender","OkControlID":"ctl00_ContentPlaceHolder1_OkButton","OnOkScript":"onOk()","PopupControlID":"ctl00_ContentPlaceHolder1_Panel1"}, null, null, $get('ctl00_ContentPlaceHolder1_LinkButton1'));
});
In my application - all of my urls are dynamically served... and so for instance for this page url: /localhost/SitesEasyTest/admin/EditNamedPages/default.aspx
The following gets generated:
Sys.Application.add_init(function() {
$create(AjaxControlToolkit.ModalPopupBehavior, {"BackgroundCssClass":"modalBackground","DropShadow":true,"DynamicServicePath":"/SitesEasyTest/default.aspx","id":"PopUp","PopupControlID":"ctl00_ctl00_ctl00_PanelModal"}, null, null, $get('ctl00_ctl00_ctl00_Target'));
It is not grabbing the actual url that it should. In the ModalPopUp example and in my own code the DynamicServicePath is not declared it is added by the toolkit at runtime....
I attempted to correct the value via code behind:
MyPopUp = (ModalPopupExtender)GetOptionalControl(skin, "MyPopUp");
MyPopUp.DynamicServicePath = (CommunityGlobals.CalculatePath("Default.aspx")); // properly generates relative path url to the dynamic page
However, the following error is displayed when compiled and tested in a browser:
DynamicControlID must be set
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: DynamicControlID must be set
[ArgumentException: DynamicControlID must be set]
AjaxControlToolkit.DynamicPopulateExtenderControlBase.EnsureValid() +372
AjaxControlToolkit.ExtenderControlBase.GetScriptDescriptors(Control targetControl) +98
Microsoft.Web.UI.ExtenderControl.Microsoft.Web.UI.IExtenderControl.GetScriptDescriptors(Control targetControl) +7
Microsoft.Web.UI.ScriptControlManager.RegisterScriptsForExtenderControls() +187
Microsoft.Web.UI.ScriptManager.OnPreRender(EventArgs e) +402
System.Web.UI.Control.PreRenderRecursiveInternal() +77
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1360
|
In either case - the script generated does not generate a DynamicControlID by defaultand so it is puzzling why trying to 'correct' what is incorrect by ovveriding the value - would cause the error?
Does the DynamicServicePath have any purpose if you are not using the dynamic population feature? Otherwise can chalk this up as being a potential issue down the road if I start to use the dynamicservices features....
While overall, this doesn't really impact me, it does pose two questions:
1. Why is it being added to begin with?
2. Why isn't it picking up the proper url considering that all this stuff supposedly gets 'connected' in the pre-render phase of the page life cycle...
Well, after digging around the Toolkit source - I discovered the issue was actually in the ServicePathConverter.cs. The way they define the path is using:
HttpContext.Current.Request.FilePath.
That is all fine and dandy and if your site is strictly based on the file system and not dynamically rendered from the database, this will work. However, for those of us whom have URL remapping - the actual correct method to obtain the url is using:
HttpContext.Current.Request.RawUrl
RawUrl() will allow those using both, either or File Systems or Database served requests.
Just change it in your ServicePathConverter.cs - recompile the toolkit to implement the fix until or if this is changed in any subsequent releases of the toolkit.