XHTML Validation Module Enhancement

Your DisplayName here! — Wed, 13 Aug 2008 23:12:04 GMT

I have been using Josh Twist’s XHTML validation module for a while and I have added a couple of small enhancements I have found useful:

It works without internet access as I included the required DTDs as embedded resources. I usually have internet access when I’m using it, but it is a big problem if I don’t.
It doesn’t validate ASP.NET trace output if it is present in the page. This is checked using the trace configuration section. I have not found a way to know if trace output is enabled in the current request.
I have added an attribute called showErrorsOnly to the validatorModule element to avoid calling the Renderer.Render method if there isn’t any error. That way, if the page validates successfully no message is shown.

Download validator_binaries (42,78 KB)

Downlaod Validator_source code (44,04 KB)

How to fix the most annoying ASP.NET 2.0 bug (TreeView XHTML compliance)

Your DisplayName here! — Thu, 25 Oct 2007 07:38:14 GMT

Or at least, one of them.

If you have used the TreeView control in ASP.NET and tried to validate your page against XHTML 1.0 transitional you’ll have the unpleasant surprise to see that the TreeView does not produce compliant code because of this:

<script>

<!--

    function TreeView_PopulateNodeDoCallBack(context,param)
{

        WebForm_DoCallback(context.data.treeViewID,param,TreeView_ProcessNodeData,context,TreeView_ProcessNodeData,false);

    }

// -->

</script>

The generated script code does not have the required type='text/javascript' attribute.

It is sad that Microsoft didn’t find this bug out before releasing asp.net 2.0. They should work with something like this xhtml validation module when testing their controls. The fix for this problem is trivial, just add the type attribute to the injected script and everybody is happy.

However, this is one of the cases that really annoy people. For some “never to be understood” reason, Microsoft closed this bug as “Won’t fix”. I can’t give you the link to the bug report as Microsoft Connect is not working for the last 2 days.

You can use the CSS Control Adapter to fix this, or use a third party TreeView. However, that is no excuse to not having this bug fixed. I can understand that they don’t fix bugs like the poor extensibility of the ParameterCollectionEditor as there is a lot of work (however, even if I understand that, I think that it should be fixed. If it is a lot of work is because of bad design. If it has been designed with extensibility in mind things like this will not happen as often) but this trivial bug to fix has no excuse.

Yesterday I faced against this bug again and was too angry to be able to keep working without doing anything about it. I used reflector to see if there was any way to fix the bug without having to recreate the full TreeView class and I was lucky.

The TreeView uses IsClientScriptBlockRegistered and RegisterClientScriptBlock to register the invalid script code, so registering a valid script code before has to work, and indeed it does:

using System;

using System.Web.UI;

using System.Web.UI.WebControls;

namespace Manu.Web.UI.WebControls

{

    /// <summary>A
TreeView that fixes the most annoying ASP.NET 2.0 bug ever!.</summary>

    public class FixedTreeView : TreeView

    {

        #region Fields

        protected static string populateNodeScript
= "\r\n<script type='text/javascript'>\r\n<!--\r\n   
function TreeView_PopulateNodeDoCallBack(context,param) {\r\n       
";

        protected static string populateNodeScriptEnd
= ";\r\n    }\r\n// -->\r\n</script>\r\n";

        #endregion

        #region Methods

        /// <summary>Raises
the PreRender event.</summary>

        /// <param
name="e">An System.EventArgs that
contains event data.</param>

        protected override void OnPreRender(EventArgs e)

        {

            ClientScriptManager clientScript
= Page.ClientScript;

            //
register a correct script code before the TreeView

            if (!clientScript.IsClientScriptBlockRegistered(base.GetType(), "PopulateNode"))

            {

                clientScript.RegisterClientScriptBlock(base.GetType(), "PopulateNode",
populateNodeScript + clientScript.GetCallbackEventReference("context.data.treeViewID", "param", "TreeView_ProcessNodeData", "context", "TreeView_ProcessNodeData", false)
+ populateNodeScriptEnd);

            }

            //
do the original processing

            base.OnPreRender(e);

        }

        #endregion

    }

}

It is sad to have to resort to this even in the next ASP.NET version. Hopefully a Microsoft guy can fix this in time for the next ASP.NET version.

Manuel Abadia's ASP.NET stuff - XHTML

XHTML Validation Module Enhancement

How to fix the most annoying ASP.NET 2.0 bug (TreeView XHTML compliance)