2670

More On ASP.NET Validators And Validation Summary Rendering of Properties

On previous posts [^][^] I mentioned the size of ASP.NET validators and validation summary rendering and the fact that expando attributes are being used to add properties. Mohamed also mentions this issue.


Besides the fact that custom attributes aren't XHTML conformant, Firefox differs from Internet Explorer in the way it handles these attributes.


On Internet Explorer, these attributes are converted in string properties of the HTML element. On Firefox, on the other hand, these attributes are only accessible through the attributes collection.


I wonder why I don’t like client-side JavaScript development.

Rendering ASP.NET Validators And Validation Summary Property As HTML Attributes

Yesterday I blogged about the cause of ASP.NET validators and validation summary slowness.


At that point I wasn't aware of the existence of the XHTML conformance configuration (thanks Nuno).


With the XHTML conformance configuration set to Legacy, the rendering of controls works like it worked in ASP.NET 1.1.

The Cause Of ASP.NET Validators And Validation Summary Slowness

When building ASP.NET pages, if you use too many validators and validation summaries your pages can become very slow. Have you ever wondered why?


Lets build a simple page web page with a few validators. Something like this:


Web page with validation


The page is composed of:



ASP.NET renders the ValidationSummary as a DIV and each validator as a SPAN and uses expando attributes to add properties to those elements.


According to the documentation, expando attributes are set dynamically from JavaScript to preserve XHTML compatibility for the rendered control's markup.


The problem is that all that JavaScript makes the HTML document larger and slower to execute than if the properties were rendered in HTML as attributes of the elements.


For such a small page, the difference in size approaches 2k bytes. If you add a few dozen validators to he page, the slowness is noticeable.


I'm all in favor of strict standards and standards compliance, but in this case, I wish XHTML would allow arbitrary attributes.

Upgrading the WCSF EventBroker Extension to WCSF 2.0

While preparing the demos for my session at TechDays Portugal 2008, I've noticed some changes in the Web Client Software Factory 2.0 that prevented the EventBroker Extension from compiling and running.

The problem ended out just being a little change in the WebClientApplication class. The virtual methods related to creating the builders changed.

To fix this, all it's needed is editing the WebClientApplication class (CompositeWeb\WebClientApplication.cs, line 35).

Just replace the CreateBuilder override:

protected override Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilder CreateBuilder(bool isSingleton)
{
    // Our builder adds an EventBrokerStrategy to the build.
    WCSFBuilder builder = new WCSFBuilder();
    builder.Policies.SetDefault<ISingletonPolicy>(new SingletonPolicy(isSingleton));
    return builder;
}

with an override of the AddBuilderStrategies method:

protected override void AddBuilderStrategies(IBuilder<Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderStage> builder)
{
    base.AddBuilderStrategies(builder);
    builder.Strategies.AddNew<EventBrokerStrategy>(Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderStage.PostInitialization);
}

Don't forget that if you want to run it in IIS7 Integrated Pipeline mode, you have a few more changes to make.

WCSF 2.0 And IIS7 Integrated Pipeline Mode

While preparing the demos for my session at TechDays Portugal 2008, I've noticed that the Web Client Software Factory 2.0 doesn't work with IIS7 in integrated pipeline mode because it's trying to access the Request property of the current HTTP Context from the HTTP Application Start "event", which is not available at this point.


This is an already known issue and you can vote to get it solved.


Meanwhile, there are two ways to work around this:


Changing the Composite Web Application Block


If you are comfortable with having your own build of this block instead of the provided strong named one, you only need to change one statement in the WebConfigModuleInfoStore class (WCSFBlocks-Feb2008\CompositeWeb\Source\CompositeWeb\Services\WebConfigModuleInfoStore.cs, line 105).


Just replace:

configuration =
WebConfigurationManager.OpenWebConfiguration(context.Request.ApplicationPath + "/" +
configFilePath.Replace(context.Request.PhysicalApplicationPath, ""));

with:

configuration =
WebConfigurationManager.OpenWebConfiguration(HttpRuntime.AppDomainAppVirtualPath + "/" +
configFilePath.Substring(HttpRuntime.AppDomainAppPath.Length));

Changing the application


If you prefer to (or have to) use the provided and strong named version of the Composite Web Application Block, you can always change your application.


Just open the generated global.asax file:

<%@ Application Language="C#" Inherits="Microsoft.Practices.CompositeWeb.WebClientApplication" %>

and add:

<script RunAt="server">

private bool initialized;

protected override void Application_Start(object sender, EventArgs e)
{
this.initialized = false;
}

protected void Application_BeginRequest(object sender, EventArgs e)
{
if (!this.initialized)
{
this.initialized = true;

base.Application_Start(sender, e);
}
}

</script>

Web Client Software Factory 2.0 shipped

Web Client Software Factory 2.0

February 2008 Release

 

Resources

About the Deliverable

The Web Client Software Factory (WCSF) provides a set of guidance for architects and developers building enterprise Web applications. The factory includes samples, reusable code and a guidance package which automates key development tasks from within Visual Studio.

Using the Web Client Software Factory assets, developers can create Composite Web applications composed of independently developed and deployed modules. These modules are dynamically brought together at runtime into a common shell. Additionally the factory includes support for ASP.NET AJAX thus providing users with a richer and more responsive user experience.

New In This Release

The February 2008 release of the Web Client Software Factory has the following improvements to the June 2007 release.

  • Full support for Visual Studio 2008 and .NET Framework 3.5
  • Added ASP.NET AJAX extenders for Context Sensitive Autocomplete, AJAX Validation, and Real Time Search that can be used in existing ASP.NET sites and ASP.NET sites built using the Composite Web Application Block.
  • Added UI Composition capability through extending our dependency injection mechanism to support Pages, User Controls and Master Pages.
  • Added Dependency Injection on ASMX Web Services and JSON services.
  • Added a new set of Quickstarts and How-To topics on MVP, Modularity and the new AJAX extenders
  • Added a new Order Entry Reference application that demonstrates all of the new functionality.

In addition, this release of WCSF has the following community issues and fixes:

  • 42 Workitems closed including the top-voted items on CodePlex
  • Add ASP.NET AJAX Support (97 votes)
  • Web Client Software Factory Support for Enterprise Library 3.1 (62 votes)
  • Services through configuration (32 votes)
  • Support for using the Validation Application Block (16 votes)
  • Recipe support for Visual Basic .NET (20 votes)
  • Added Presenter support for Master Pages (11 votes)

FormsAuthentication And Query String Parameteres

Today I ran into this strange"feature" of ASP.NET:

When redirecting to the login page, the query string parameters are encoded with the requested URL into the ReturnUrl query string parameter of the request to the login page, but are also in the query string of the request to the login page.

Here is an example:

When requesting:

http://localhost:5014/FormsAuthentication/default.aspx?test=true

we are redirected to:

http://localhost:5014/FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx%3ftest%3dtrue&test=true

See the test parameter?

As far as I know, this is not documented or overridable.

WCSF geekSpeak: Download Available On Channel 9

BUG UPDATE: Using Custom Identities in ASP.NET fails when using the ASP.NET Development Server

Sometime ago I reported this bug. Looks like there's a workaround for it. Find more about it here.

WCSF geekSpeak: Download Available At MSEVENTS

For those who missed my webcast (and wanted to watch it) it's available to download at the MSEVENTS site.