November 2003 - Posts
Just a short note to those who are messing with a control's CssStyleCollection behind the Style property...
Even tho css style property names are case insensitive according to the css spec, the CssStyleCollection is case sensitive with it's keys. Therefore the following:
<script runat="server" language="c#" >
protected void Page_Load( Object sender, EventArgs e ) {
Result.Text = "Foo";
Result.Style["COLOR"] = "BLUE";
Result.Style["color"] = "red";
}
</script>
<html><body><form runat="server" >
<asp:Label runat="server" Id="Result" />
</form></body></html>
Results in the following style:
<span id="Result" style="COLOR:BLUE;color:red;">Foo</span>
Personally, I think this is rather... wrong. In case you want to know why this matters... I came across it while trying to transfer the “grid layout” style properties that vstudio makes from one control's style to another's. Vstudio uses uppercase style declarations, which, apparently and unfortunately, matters.
I'm sure this will get a lot of attention fairly quickly... but just wanted to point out that
the Eolas plugin patent is under review by the patent office. Hopefully this problem will indeed go away.
Jesse Ezell piped up about what he saw as a design flaw in the Membership Provider that ships with Whidbey. Rob Howard then commented and blogged about the asp.net teams decision-making process there, saying that they had struggled over the same issues.
I've been doing some provider work myself, on a little pseudo-secret project I've been working on for a while, and I've come to my own conclusions on the issue. I think that the System.IO guys got it right with the Stream class. Instead of an IStream interface, or a IReadStream/IWriteStream/ISeekStream interface mess, they have an abstract Stream class that has the Read/Write/Seek methods. Of course, not every stream can support these ideas, but just trying to call them, waiting for a exception, isn't the right path, so they also included CanRead, CanWrite, CanSeek properties.
This model, where you can query the implementor for it's supported functionality, gives you a great story for both developing custom provider implementations that can't suppport everything, but support what you need, as well as extending the the base provider with new methods without fear of breaking current versions implementations.
I just wanted to bring everybody's attention to an insightful newsgroup post by Peter Blum where he exposes a design flaw in the datagrid that affects all control builders out there that emit clientscript.
The summary:
If your control is in a template column of a datagrid, and that column has its Visible property set to false, then your OnPreRender method will still get called. Normally, if Visible is false, because of direct property set or parent visibility, then OnPreRender does not happen. Since most people use OnPreRender to emit/register clientscript, this can cause script to be emitted even tho the control will not be rendered.
This is an especially insidious problem, because your control works just fine in normal testing scenarios. Who would have thought to check for putting the control in an invisible column in a datagrid.
The workaround to avoid script errors in browsers, of course, is to always check for null values from calls to document.getElementById, which would indicate that your control wasn't really rendered to the browser even tho the script was. However, as Peter pointed out, it's a complete waste of bandwidth to emit potentially large scripts when all the controls that the might need the script were never actually rendered.
I guess I'll have to do a code review soon to make sure I'm doing the right thing for this scenario.
More Posts