Posted on May 20th, 2011%
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 . . .
→ Read More: CSS Friendly Control Adapters now available on NuGet
Posted on November 16th, 2010%
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. . . . → Read More: MVC model validation with Castle Validator
Posted on December 3rd, 2007%
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.
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
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.
<OutputPath>bin\</OutputPath>
. . .
→ Read More: How to change a Visual Studio 2005 class project to a web project
Posted on March 27th, 2007%
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 . . .
→ Read More: WebForms and alternatives: You can’t convince everyone
Posted on March 23rd, 2007%
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 web programming (before ASP.Net), who are used to coding HTML and JavaScript by hand, or who are used and comfortable with injecting presentation code into web pages will feel comfortable with MonoRail.
- 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.
. . . → Read More: Yet another comparison of MonoRail vs WebForms
