Back in the days of Web Forms, there were server controls, and they generated rather CSS-unfriendly HTML. So, Microsoft got someone (Russ Helfand) to write adapters that changed their rendering to be more CSS-friendly: the “CSS Friendly Control Adapters” were born.
A little less farther back, in 2007, I tried convincing some people at Microsoft to let the community continue development of these adapters, and they agreed. The CSSFriendly CodePlex project was born, and a bunch of bugs and some new features were added.
A lot has changed since then, but the adapters still have use today for people stuck on .Net 2.0 (they’re in the top 200 most downloaded CodePlex projects, and their forums still see activity). To facilitate those who still use CSSFriendly, I’ve added the library package to NuGet.
How to use the CSSFriendly NuGet package
In four easy steps (three if you already have NuGet).
- First, you need Visual Studio 2010 and NuGet. (If you’re new to NuGet, read the getting started documentation.)
- Next, right-click the References folder and choose Add Library Package Reference.
- In the Add Library Package Reference window, search for “cssfriendly.”
- When you see the CSSFriendly package, click the Install button.
After it installs, the following is added to your project:
- The CSSFriendly library reference
- The CSSFriendlyAdapters.browser file in the App_Browsers folder
At that point, you’re ready to go!
The full source of the CSSFriendly library is still available at CodePlex: http://cssfriendly.codeplex.com. Downloads there include sample code and walkthroughs.
Enjoy, and let me know if you have any issues!
The ASP.Net MVC framework comes with built-in model validation using the Data Annotation validators. Unfortunately, the Data Annotations aren’t as robust as other validation libraries, such as the Castle Validators.
Implementing a custom model validator (for server-side validation — client-side validation requires more than is covered in this post), you need to write an implementation of the ModelValidator and ModelValidatorProvider classes that support the Castle Validators.
An example of how to do this follows. Though it hasn’t been fully tested, it worked for a handful of situations I experimented with. Use this as a starting point for your own server-side model validator implementation. Continue reading
I tend to create new Visual Studio projects using the class library template, then make it into what I want. Sometimes, what I want is a web project. Through the project properties view, you can change a project between a class library, windows application, or console application with ease — but there’s no easy way to change to a web project.
Fortunately, there is an easy way to do it.
Open your VS2005 project file (ending in
.csproj) in a text editor. Add a new line (shown below) to the first
, usually one of the first few lines in the file.
Save the file and reopen your project. Viola! It’s a web project. But there is a bit more to do. Find each <OutputPath> line, and set remove the Debug or Release (or any other) folder, so it just reads as follows.
Since starting with MonoRail some months ago, I’ve joined the bandwagon touting its benefits over Web Forms. Part of my advocacy was to convince the developers who help me out with my online baseball game, CSFBL (which will be rewritten using MonoRail).
In a discussion on our BaseCamp site, one of those developers, Rick, said this. (Emphasis added by me.)
I finally got to spend some time with MonoRail on Friday at work… [T]he guy that sits next to me does dev work on a fairly complex ASP site… He’s just got tasked to add a whole new section of his site and he doesn’t want to do it in ASP and we both got tasked to start learning each others projects so that we can back each other up when one of us is out so we decided to give MonoRail a look. He had spent all week just trying to get up to speed on ASP.Net and he was getting very frustrated… we spent about an hour going through the first tutorial before we both got interrupted to do other things, but we liked what we saw so far. We plan on picking up right where we left off first thing Monday morning.
I read your latest blog post about MonoRail vs ASP.Net and I’m one of those coming from the VB background that found Web Forms easy to learn. But after looking at all your links and the demos I can’t wait to learn this stuff. You nailed it on the head at the end when you said you’d rather learn this than fight with the GridView… that’s the part of Web Forms that I hate. I can’t count the hours I’ve wasted on the old DataGrid in ASP.Net 1.1 and my coworker spent all week fighting with the Wizard and GridView controls.
Cool stuff, indeed. Unfortunately, it’s not so easy to convince everyone. Here’s a follow-up reply he made. Again, emphasis added is mine.
My reply went something like this.
The good thing about all of this is we have options: Web Forms, MonoRail, and many others. What’s better for one person (or one project) is not necessarily better for everyone (or all projects). People should try different solutions, and ultimately choose the one based on what are you most comfortable with and what makes you a better, more efficient developer.
It seems everyone is writing about the differences between MonoRail and WebForms these days. Not to be left out, I’ll throw a few of my own comments into the mix.
I think that one’s attraction (or hatred) of MonoRail or ASP.Net’s WebForms is based on their programming background. (At least, it is in my case, and that’s at least one person, so that statement can’t be totally wrong.)
- People who come from the old days of Visual Basic programming or whose experience with web programming is WebForms and ASP.Net will feel comfortable with ASP.Net.
For all its flaws, WebForms has a lot of power, but the power comes at a price. Web forms does a lot for you, which is its benefit and its bane. If you want total control of your application, you’ll be frustrated with WebForms. MonoRail leaves a lot of things in your hands (particularly on the presentation side), and tries to help you do things rather than do things for you. That’s a big difference.
One of the reasons for the popularity of ASP.Net and WebForms (aside from Microsoft, of course) are the many web controls that come built-in or that you can buy to extend your application’s capabilities without having to write your own complex code. The same issues described above, however, still apply. Whenever you rely on a web control to do a complex task for you, you’re sacrificing some control.
That’s not to say there are no "web-control-like" solutions for MonoRail. There are many community-developed scripts and code blocks that can be used to extend the functionality of a web site built on MonoRail, providing features similar to web controls with less mysterious baggage. Consider the following.