When writing accessible websites, we are told that frames are wrong. But with web-applications for the local intranet of your company or your customers, frames can be very useful. But why is it that we ASP.NET developers rarely use frames for our web-applications? Not because we don't like frames, but because ASP.NET limits us to the page we are currently building, disallowing us to reach out of our 'frame' and altering other frames, without refreshing them constantly.
This article is part two of a trilogy, in which I present the
AnywherePlaceHolder. A control that functions like a normal
If you did not read the first part of this article, I'd advice you to read that first: The AnywherePlaceHolder. Part 1: The Simple AnywherePlaceHolder.
In the first part of this article, I presented the
BaseAnywherePlaceHolder and the
SimpleAnywherePlaceHolder was only used to explain the basics of the real
AnywherePlaceHolder that will now be explained in part 2. The
SimpleAnywherePlaceHolder can write normal controls like
GridViews to any desired frame.
In this part, I will explain the working of the
In part three, I will explain the working of the
AnywhereValidationSummaryPlaceHolder. This is a
AnywherePlaceHolder with the functionality of a normal
ValidationSummary. This is a
BaseAnywherePlaceHolder with the functionality of a normal
ValidationSummary. This special
PlaceHolder allows you to write your custom messages and validation error messages into the frame of choice.
This project is written for ASP.NET 2.0, and will not compile under .NET 1.x. However I believe that it can be ported back to .NET 1.x, with a little bit of effort.
Using the code
In this part, we'll be examining the
AnywherePlaceHolder class. Below is the class diagram.
SimpleAnywherePlaceHolder had. First of all, the
AnywherePlaceHolder searches its own control hierarchy to find
Button controls that have their
UseSubmitBehaviour property enabled. Submit buttons are real nasty animals when injecting code. Logically, because the submit behavior of a
Button has no effect, without a
Form element. So what we must do is set the
UseSubmitBehaviour of all
false before we buffer the child controls' HTML code.
The submit has also a really important feature. A
Form can force a submit when return is pressed within an input control on the page. This allows the user to use the page without the mouse. So when we remove the
Buttons from the source this feature will disappear. Iterating all child controls is done with the
ControlTree class. Explaining this class is beyond the scope of this article. Download the source code and see how this is implemented.
The solution for this is rather simple. Render the
Button controls normally in the source frame with their "submit" behavior enabled, but hide them using the stylesheet '
display' property. Remember the
source.style.display = 'none'; line from part one?
Okay, now we fixed the problem with the submit buttons, but still no button will work, because every ASP.NET
SourceFrame property in the
BaseAnywherePlaceHolder class. The
ConvertSourceCode method is noted below:.
protected string ConvertSourceCode(string sourceHtmlCode)
StringBuilder destinationHtmlCode = new StringBuilder(sourceHtmlCode);
destinationHtmlCode.Replace("this.document.", this.SourceFrame + ".");
As you can see, the method loops through the
To wrap things up
You have seen that with minimal coding you can create the
AnywherePlaceHolder that can beam virtually every control from one frame to another with the speed of light.
Buttons, even complete
Tables can easily be transported between the frames. But as you already know, there is another part of this article, so what is still missing in this concept? Missing is the possibility to put a
ValidationSummary component in another frame. The
AnywhereValidationSummaryPlaceHolder will deal with this in The AnywherePlaceHolder. Part 3: The AnywhereValidationSummaryPlaceHolder!
- 22 August, 2005 - Version 1.0. Initial version.