Sort of bug due to using GUIDs as identifiers for controls
Ok, this is a fun one! When you add a form field it's given an id of the GUID of the field. All good so far. This works ok with the default formn controls, but it falls over if you try and add a new field type that has it's own validation controls as part of its code (rather than the built in regex/mandatory ones).
.Net uses the id of the validation control as the variable name of the validator control in the javascript it emits. This means that validation controls inside the field type cause a javascript error, because it generates a javascript variable with the guid in it, which contains dashes, which is invalid javascript, and breaks the javascript on the page.
The default validators are ok, as they are rendered at the same level as the control with the guid, so its not in their variable names. Anything that's part of the field though, and it dies, as it's under the control, and gets the guid as part of it's name/id.
Obviously I don't have the source for Contour to try and resolve this myself, so is there anything that could be done in a future release to fix this behaviour? I appreciate it'll only affect the tiny minority who end up having to integrate other controls into Contour though!
At the moment, the only thing I can think of is to maybe try and do some horrendous hack involving using regex's to look for broken js strings and fix them on PreRender or Render, but that's going to have performance implications....... Any other ideas welcome!
Right. Have created the following hack to make this work, I've only tested it with the control I was integrating, but I can't see why it wouldn't work with any other control that implements it's own valiadtion controls when trying to get it to work in Contour as a field type.
**WARNING** this code might break canvas mode, but I don't use it, so its not an issue for me.
Basically, add the following code to the top of the template for your form pages (you could add it to the root template if you wanted, but I wouldn't, for performance reasons, just add it to the templates where the problem forms will be):
<script runat="server"> //overrides the page rendering to allow us to move the asp.net viewstate field to the bottom of the form (SEO) protected override void Render(System.Web.UI.HtmlTextWriter writer) { System.IO.StringWriter stringWriter = new System.IO.StringWriter(); HtmlTextWriter htmlWriter = new HtmlTextWriter(stringWriter); base.Render(htmlWriter); String html = stringWriter.ToString(); if (html.IndexOf("_RenderForm_") > 0) { //run regex to remove the "-" from the javascript and replace it with "_" instead Regex regEx = new Regex(@"var ([a-zA-Z_0-9\-]*(?<=\-)[a-zA-Z_0-9]*)"); MatchCollection matches = regEx.Matches(html); for (int x = 0; x < matches.Count; x++) { string match = matches[x].Value;
//replace variable name html = html.Replace(matches[x].Value, match.Replace("-", "_"));
//replace uses of variable match = match.Substring(4) + "."; html = html.Replace(match, match.Replace("-", "_")); }
Basically, it checks if the page has a contour form on it first (looking for "_RenderForm_" in the generated page code), then uses a combination of a regex to find the broken js variables along with an extra bit of code to replace the variable name and all references to it in the page code. The code isn't brilliant, I'm sure it could be optimised better with a bit of effort, but on the offchance that you run into the (admittedly uncommon) set of circumstances that cause this problem, hopefully this bit of code might help! Note: this code should fix multiple broken js validation variables, if you have more than one on a page.
I've submitted a bug report to MS to point out that its a bit lame that their framework will emit broken JS (it would make sense for their code to check for things like dashes in object ids and adjust the javascript output accordingly), but I don't expect anything to come of it!
Sort of bug due to using GUIDs as identifiers for controls
Ok, this is a fun one! When you add a form field it's given an id of the GUID of the field. All good so far. This works ok with the default formn controls, but it falls over if you try and add a new field type that has it's own validation controls as part of its code (rather than the built in regex/mandatory ones).
.Net uses the id of the validation control as the variable name of the validator control in the javascript it emits. This means that validation controls inside the field type cause a javascript error, because it generates a javascript variable with the guid in it, which contains dashes, which is invalid javascript, and breaks the javascript on the page.
The default validators are ok, as they are rendered at the same level as the control with the guid, so its not in their variable names. Anything that's part of the field though, and it dies, as it's under the control, and gets the guid as part of it's name/id.
Obviously I don't have the source for Contour to try and resolve this myself, so is there anything that could be done in a future release to fix this behaviour? I appreciate it'll only affect the tiny minority who end up having to integrate other controls into Contour though!
At the moment, the only thing I can think of is to maybe try and do some horrendous hack involving using regex's to look for broken js strings and fix them on PreRender or Render, but that's going to have performance implications....... Any other ideas welcome!
:)
Right. Have created the following hack to make this work, I've only tested it with the control I was integrating, but I can't see why it wouldn't work with any other control that implements it's own valiadtion controls when trying to get it to work in Contour as a field type.
**WARNING** this code might break canvas mode, but I don't use it, so its not an issue for me.
Basically, add the following code to the top of the template for your form pages (you could add it to the root template if you wanted, but I wouldn't, for performance reasons, just add it to the templates where the problem forms will be):
<script runat="server">
//overrides the page rendering to allow us to move the asp.net viewstate field to the bottom of the form (SEO)
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
System.IO.StringWriter stringWriter = new System.IO.StringWriter();
HtmlTextWriter htmlWriter = new HtmlTextWriter(stringWriter);
base.Render(htmlWriter);
String html = stringWriter.ToString();
if (html.IndexOf("_RenderForm_") > 0)
{
//run regex to remove the "-" from the javascript and replace it with "_" instead
Regex regEx = new Regex(@"var ([a-zA-Z_0-9\-]*(?<=\-)[a-zA-Z_0-9]*)");
MatchCollection matches = regEx.Matches(html);
for (int x = 0; x < matches.Count; x++)
{
string match = matches[x].Value;
//replace variable name
html = html.Replace(matches[x].Value, match.Replace("-", "_"));
//replace uses of variable
match = match.Substring(4) + ".";
html = html.Replace(match, match.Replace("-", "_"));
}
Page.MaintainScrollPositionOnPostBack = true;
}
writer.Write(html);
}
</script>
Basically, it checks if the page has a contour form on it first (looking for "_RenderForm_" in the generated page code), then uses a combination of a regex to find the broken js variables along with an extra bit of code to replace the variable name and all references to it in the page code. The code isn't brilliant, I'm sure it could be optimised better with a bit of effort, but on the offchance that you run into the (admittedly uncommon) set of circumstances that cause this problem, hopefully this bit of code might help! Note: this code should fix multiple broken js validation variables, if you have more than one on a page.
I've submitted a bug report to MS to point out that its a bit lame that their framework will emit broken JS (it would make sense for their code to check for things like dashes in object ids and adjust the javascript output accordingly), but I don't expect anything to come of it!
:)
Comment author was deleted
Hi Tim,
Thanks for the details, I'll take a look at this for our next maintenance release (will probably just update field id's to avoid this in the future)
Cheers,
Tim
Comment author was deleted
@Tim, this has been updated and will be part of the maintenance release coming later today
is working on a reply...