Short Server Control Rant
I came across another reason today why building cool server controls is way too complicated in VS.NET. Two words: XSD Schemas. I wanted to give ScrollingGrid a schema so that it doesn't freak out on anyone, so I thought I'd be sneaky and add the following line to the end of the element definitions in asp.asd:
<xsd:element name="ScrollingGrid" type="DataGridDef" />
Since we already inherit from the DataGrid, it should have worked for 85% of the attributes in the tag. But it didn't work. Well, I take that back. It worked great if I changed the ASPX tag to <asp:ScrollingGrid>. But since ASP.NET would crap out on that, it wouldn't work. So I figured, “Well, if the XSD file is named the same as the tag prefix, VS.NET should load it into memory automatically.” So I copied the asp.xsd file to interscape.xsd, and re-opened Visual Studio. No dice.
So I found out the only way I can do this is to add design-time directives to code that will render in the browser, adding unnecessary bytes to the HTML downstream, and makes ONE MORE step that I have to put my users through. I hate that.
Part two of this problem is that in ASP.NET, two controls cannot share the same tagPrefix. There is no reflection system in place that will reflect through all the assemblies referenced by the same prefix, to find the class referenced in the declarative markup. This means that the system I described earlier wouldn't work either, because all my controls would have to reside in the same assembly, which isn't going to happen anytime soon. Because there would be no common-sense naming convention that would allow everyone else besides Microsoft to use a unified tag structure, I would HAVE to use the xmlns tag to do the dirty work.
As you can see, the current implementation is less than ideal. I sure hope it gets better soon. Either way, a search of Google confirms that this would be one of the first times anyone has talked about the problems with this system in public (AFAIK, anyways). I really wish people would be more open about this stuff. Too many people are keeping their server control secrets under lock and key. I'm not the first developer in the world to build a server control for retail distribution, but from the information available online, you might be lead to believe otherwise. Isn't that something the CVC should be doing? Or do I need to be a member of the elite server control club to get access to that information? Grr.... that's another rant for another day.
Just think how effective I could be if I didn't have to spend half of my time trying to circumvent the limitations of the current toolset. Whidbey won't be here soon enough.