Mails we've received, forum discussions, and recent Splorp posts
all complain that .NET's built-in tools and controls generate invalid
XHTML and CSS. The workaround? Don't use the built-in tools and
controls. The value of .NET without those built-in tools and controls?
Not much.
.NET is Microsoft's platform for web services. It derives it power
from XML, a web standard. A product based on one open standard should
support others, not break them.
When Microsoft does the wrong thing, developers feel helpless. You
are not helpless. You have a choice of development platforms. [Zeldman]
(emphasis mine) The choice is simple, use J2EE ~ where the flexibility is free! 
Just in case anyone is interested, I thought I'd report on how Professional JSP 2.0 (now being published by Apress) is progressing. I received some initial feedback that my Struts/XDoclet chapter would not be included in the book, but would be a separate download (I'd still get paid for it though). Most of the reasons seemed to be indicating that the chapter was too advanced - newbies wouldn't get it. Personally, I hate reading newbie books, so why would I write a newbie chapter? I also hate simple sample apps, that's why I wrote a fully functional one. Anyway, I convinced them that this chapter did have value and now they are going to include it in the book, but as a case study rather than a regular chapter.
As for the security chapter, they said they really liked the content, but (again) the example was too advanced. I have been asked to remove XDoclet as a dependency since I don't explain it until the Struts chapter. This turned out to be a lot easier than I thought it'd be - only took me about an hour last night. I simply built the project with XDoclet, and then copied the artifacts (web.xml, generated ValidatorForms, struts-config.xml, validation.xml, *.hbm.xml, etc.) back into the source tree. I then tweaked the build.xml file to pick up the artifacts, ran "test-all" and voila - it worked?!
The lesson I learned from all this is that XDoclet is great for rapid development - but possibly only while you you are developing new features. Once an application stabilizes or development is discontinued (I don't plan on further developing security-example), it's pretty easy to strip out the XDoclet dependency and (probably) make it easier for users to understand.
Just kidding. It's just that the ol' bandwidth issue has reared its ugly head again. I sent the following message to Keith last night:
Am I reading this stats page correctly?
Am I already over my KB limit for the month?
His response:
Wow, you've almost 3/4 million hits already this month....
It looks like it averages about 7.7K per hit, so yep, you appear to be over 5
GB already this month.
I only have a 5 GB plan, so I asked him how much it would be to move to a 10 GB plan (no response yet). Why don't I just move? Because I like Keith, and ever since I moved to the new server, stability has been awesome. I pay $30/month for the 5 giger, so hopefully I can get the 10 GB for an extra $10/month. Then again, according to this page, 8 GB is $80/month. Maybe I will be moving...
