sides of march » ASP.Net

CSS Friendly Control Adapters now available on NuGet

brian — Fri, 20 May 2011 23:32:56 +0000

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!

MVC model validation with Castle Validator

brian — Wed, 17 Nov 2010 03:20:49 +0000

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.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web.Mvc;
using Castle.Components.Validator;

namespace ComputerSims.Baseball.Web.Infrastructure
{
/// 
/// Implements a  for the Castle Validator library.
/// 
public class CastleModelValidator : ModelValidator
{
private readonly IValidatorRegistry _registry;

/// 
/// Initializes a new instance of the  class.
/// 
/// The metadata.
/// The controller context.
/// The validator.
public CastleModelValidator(ModelMetadata metadata, ControllerContext controllerContext, IValidatorRegistry registry)
: base(metadata, controllerContext)
{
_registry = registry;
}

/// 
/// Validates the object.
/// 
/// The container.
/// A list of validation results.
public override IEnumerable Validate(object container)
{
if (Metadata.Model != null &amp;amp;amp;&amp;amp;amp; Metadata.PropertyName == null)
{
IValidatorRunner runner = new ValidatorRunner(_registry);

if (!runner.IsValid(Metadata.Model))
{
ErrorSummary errors = runner.GetErrorSummary(Metadata.Model);

foreach (string property in errors.InvalidProperties)
{
yield return new ModelValidationResult()
{
MemberName = property,
Message = errors.GetErrorsForProperty(property)[0]
};
}
}
}

yield break;
}
}

/// 
/// Implements a  for the Castle Validator library.
/// 
public class CastleModelValidatorProvider : ModelValidatorProvider
{
private IValidatorRegistry _registry;

/// 
/// Initializes a new instance of the  class.
/// 
/// The validator.
public CastleModelValidatorProvider(IValidatorRegistry registry)
{
Guard.NotNull(registry, "registry");

_registry = registry;
}

/// 
/// Gets a list of validators.
/// 
/// The metadata.
/// The context.
/// A list of validators.
public override IEnumerable GetValidators(ModelMetadata metadata, ControllerContext context)
{
if (metadata.Model != null &amp;amp;amp;&amp;amp;amp; metadata.PropertyName == null)
{
yield return new CastleModelValidator(metadata, context, _registry);
}
}
}
}

I hope this helps those using the Castle Validators with the ASP.Net MVC framework!

How to change a Visual Studio 2005 class project to a web project

brian — Mon, 03 Dec 2007 20:52:20 +0000

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 line, and set remove the Debug or Release (or any other) folder, so it just reads as follows.


<OutputPath>bin\</OutputPath>

WebForms and alternatives: You can’t convince everyone

brian — Tue, 27 Mar 2007 14:24:51 +0000

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.

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.

Not so fast…I chatted with my co-worker this morning and he made some great progress with the GridView over the weekend and was very excited about what he could do with it. He said he’s not very excited about doing more Javascript and HTML coding and that he’d rather switch over to Web Forms. DOH! So… tomorrow we’re going to check out the Web Client Factory Software.

My reply went something like this.

Are you a web developer or not? If you are, you should know JavaScript and HTML. Otherwise, you are not a web developer, you are a Web Forms developer. There’s a big difference. There’s nothing wrong with being either; you just have to understand the constraints of both.

As for doing more JavaScript as opposed to doing more Web Forms… Just wait until you start writing OnItemDataBound event handlers for your GridView to do some custom table rendering, as opposed to simple injection into your presentation layer (i.e. web page). You’ll realize that staying with Web Forms will just mean you write more C# code to handle your presentation instead of presentation code (i.e. HTML and JavaScript and whatever is used to inject data into your presentation layer).

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.

Yet another comparison of MonoRail vs WebForms

brian — Fri, 23 Mar 2007 16:27:30 +0000

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.

I think you get the idea. All of the above are open source projects that would be difficult to use in a typical web forms project. Sure, with MonoRail you can’t use components from vendors like ComponentArt (which are very good), but I think that’s more than an adequate trade-off. And, of course, any one of the tools above can provide the same power/control trade-off of a web control, but in my experience, it is not nearly on the level of a traditional ASP.Net control.

For all the time I’ve spent implementing things on MonoRail that seem "out of the box" in WebForms, it’s no worse than the time wasted trying to figure out why a GridView doesn’t do what I expect it to, or trying to get a GridView to provide markup that it simply can’t. And I’d rather spend time learning than time debugging any day.

MonoRail vs Web Client Software Factory (WCSF)

brian — Thu, 15 Mar 2007 13:33:44 +0000

There’s a little flurry of activity going around comparing Castle MonoRail to the Web Client Software Factory (WCSF). Here’s a synopsis.

David Hayden, who admittedly is very familiar with WCSF and not very familiar with MonoRail, touts the future of WCSF and the concerns about the lack of resources working on MonoRail in order for it to compete long-term.
Scott Bellware talks about evaluating MonoRail for an enterprise application, and he mentions his horrible experience setting up and comprehending WCSF.
Hammett, one of the key Castle Project people who admittedly is not familiar with WCSF, talks about the need for WCSF to compete with MonoRail, not the other way around.

Where do I stand? Before answering, I need to explain my history with web development, ASP.Net, and MonoRail.

I started doing web development in the late 1990′s coding by hand and using ColdFusion on the server-side. I migrated to ASP and, ultimately, to ASP.Net, as most people did.

Since the beginning, I’ve had a love/hate relationship with ASP.Net. I love the .Net Framework, C#, and Visual Studio .Net. I hate ViewState, complex web controls that do unpredictable things, and the difficulty injecting JavaScript into ASP.Net web pages (id="ctl00___ctl00___ctl00_ctl00_bhcr_t___TitleBarSearchText", anyone?).

When I stumbled across MonoRail some time in 2006, I liked what I read, but didn’t have the time to explore it further. Towards the middle of 2006 I was working on my own Model-View-Presenter web architecture that was simple but effective, and even started transitioning my only claim to fame, CSFBL, to it. Then, I decided to give MonoRail a try.

I never turned back.

MonoRail is everything I wanted. It provides a simple yet powerful Model-View-Controller architecture. It avoids things like ViewState and bulky web controls. It’s a breeze marking up web pages and adding JavaScript to them. It allows me to work with the tools I like (such as my own model layer, Prototype, and Scriptaculous) without getting in the way.

As for WCSF, my experience with it was similar to Scott Bellware’s — I was frightened by the weight of it from the start, and it didn’t alleviate my existing WebForms issues. It simply didn’t stack up to MonoRail’s powerful simplicity.

Having said that, how does MonoRail compete with WCSF? I think MonoRail’s "weaknesses" are its strengths. It doesn’t try to do everything; instead, it does enough things just right. It’s scalable and super-fast. It has a reasonably short learning curve, which is more impressive considering the fact that it is lacking in documentation in some areas.

Hayden’s comment that "the MonoRail Project just does not have enough resources" doesn’t pan out. MonoRail is already an excellent, stable framework, and it didn’t get that way because its resources were lacking. There’s a big difference between "enough" resources and "not enough" resources; more does not mean better in this case. Look at Prototype or Scriptaculous; both are among the most widely-accepted JavaScript libraries around, yet neither has the backing of huge development teams with billion-dollar corporations behind them.

I’m on the MonoRail bandwagon, and plan to be for a long time.

Microsoft OKs community development of CSS Friendly Control Adapters

brian — Wed, 07 Mar 2007 18:11:59 +0000

Back in late 2006, I modified Microsoft’s CSS Friendly ASP.Net 2.0 Control Adapters to be distributable as a single DLL. Since that time, the code I wrote was downloaded from this web site, and everything seemed good, at least until the server crashed. After being prodded by a few people in the ASP.Net community, I moved this little project over to CodePlex. Before doing so, I checked to make sure this was OK with Scott Guthrie, the grand poohbah of ASP.Net at Microsoft. (You’ve got to cover your basis!)

Anyway, today I read a post on the ASP.Net forums stating that Microsoft OKs community development of the CSS Friendly Control Adapters. In short, this is a good thing for the users of this product, for reasons that are explained in that thread, and it looks like I’ll be more involved with the ongoing development of these adapters in the future. It’s also nice to see your efforts noticed by the largest software development company in the world.

I will keep the pages on this site that mentioned these adapters, but I highly suggest everyone who used them to bookmark the CodePlex project “CSSFriendly” and use that as their source of code and information going forward.

Compiled version of ASP.Net CSSFriendly Control Adapters (RTM 1.0)

brian — Fri, 24 Nov 2006 14:06:02 +0000

Last week, I released a compiled version of Microsoft’s CSSFriendly ASP.Net 2.0 Control Adapters (“CSSFriendly”). Since that post, the “1.0″ RTM version of the adapters were released. I just finished porting the latest release to a compiled assembly.

Instructions for installing and using the compiled adapters, and download links, can be found in the Projects section of this web site.

Compiled version of ASP.Net CSSAdapters (Beta 3.0)

brian — Thu, 16 Nov 2006 14:45:58 +0000

UPDATE 11/24/06: The 1.0 version of the adapters was released, so I updated the compiled distribution. Read about the update here.

UPDATE: Added a link to download just the DLL at the bottom of the entry, and rewrote some of the “implementation” steps to make them a bit clearer.

I’ve been following the progress of the CSSFriendly ASP.Net 2.0 Control Adapters (“CSSAdapters”) since they were initially launched some 6+ months ago. The team has continually worked on revising them (with a little help from me), and the latest release (Beta 3.0) seems to be something that we can live and work with comfortably.

One thing I’ve hated about the adapters is the implementation, which basically involves the following steps:

Add a file to the App_Browsers directory.
Add a folder of JavaScript files.
Add a folder of CSS files.
Add a bunch of files to the App_Code directory
Add some tags to the section of your web pages (to import the stylesheets and handle some conditional imports for IE6 and IE7).

Apparently, I’m not the only person who thinks there should be an easier way, and it seems that the folks working on the CSSAdapters agree (see the Serving Suggestions topic on the ASP.Net forums).

Inspired by the posts in that topic (especially the post by HardyE), I present to you a fully-compiled version of the CSSAdapters (Beta 3.0). A few notes on the implementation follow.

All the CSS and JavaScript files are now embedded resources — no more files to manage; everything is in one DLL.
The only CSS files embedded are those that actually do anything. In other words, I removed all but the following: DetailsView.css, Menu.css, TreeView.css, IEMenu6.css, and IEMenu7.css.
To get the JavaScript files to register (required for the MenuAdapter, TreeViewAdapter, and all controls that use the WebControlAdapterExtender), I rewrote the RegisterScripts() method to reference the JavaScript file as a Web resource (using GetWebResourceUrl()). I also added a check to IsClientScriptIncludeRegistered() which should make sure things are only added once.
To get the CSS files to link (required for the MenuAdapter, TreeViewAdapter, and DetailsViewAdapter), I added code to the RegisterScripts() method to reference the CSS file as a Web resource (using GetWebResourceUrl()). Adding them to the web page was done by parsing a tag and adding it to the page using RegisterClientScriptBlock(). As with JavaScripts, I also added a check to IsClientScriptBlockRegistered() to avoid duplication.

Implementation of the compiled CSSAdapters in a web site requires the following steps. Note that only the first step is the same as those listed above; steps #2 through #5 are eliminated by the “new” step #2 below.

Add the appropriate file to your App_Browsers directory (this step doesn’t go away, and it shouldn’t, because essentially this is a configuration file).
Add the compiled CSSAdapters.dll to your web site’s bin directory.

This makes it much easier to implement and manage than before. Note that this implementation wasn’t heavily tested, but it worked flawlessly with the CSSAdapters demo app (which is included in the distribution I’m providing here). Let me know how it works for you, or if you have any problems or suggestions.

For instructions and download links, go to the Projects section of this web site.

What the #&$^# is Windows doing this time? (and other Microsoft gripes)

brian — Mon, 30 Oct 2006 16:47:56 +0000

Yesterday, while starting up my PC out of hibernate mode (an activity done about 250 times before), after entering my username and password, Windows stared at me with a blank blue screen and a task bar (i.e. the desktop color and nothing else). Windows was certainly doing something, because the disk was thrashing. This went on for about five minutes. No activity on my part (CTL-ALT-DEL, CTL-SHIFT-ESC for Task Manager, etc.) brought about a response during those five minutes. After banging my keyboard countless times (it’s amazing I don’t break more than one a year), Windows suddenly sprang into service as if nothing out of the ordinary happened.

Can someone please tell me what the #&^$&#^ Windows was doing during those five minutes, and if it was such a mission-critical operation that NO OTHER ACTIVITIES could be taken while they ran, why there is no notice in the event log? Heck, a progress bar or meaningless popup message would have been nice.

Today, I attempt to hit the F1 key to get “help” in Visual Studio 2003 (yes, we all need help sometimes). VS2k3 has been run many times in the past, and I keep it up-to-date with the latest MSDN updates (i.e. the occasional help file updates). After pressing F1, Windows Installer pops up. Deciding to give up all hope on getting the help I need (and understanding that a random Internet search is faster than Windows Installer), I click Cancel. After about four minutes, the “Canceling…” message disappears, replaced by a new “Please wait while Windows installs…” message. I click cancel again. I shut down Visual Studio. The Windows Installer finally ended it “canceling” process after ten minutes, and I have a new message on my screen: “Microsoft Development Environment has encountered a problem and needs to close…” Yeah, yeah. Thanks for nothing.

It’s amazing how Microsoft can do so many things well, yet can’t do some of the most important things right — like make a responsive operating system. Then again, I shouldn’t expect much more. After all, this is a company that delivered an excellent development framework (.Net) yet decided that the framework includes platform-specific implementations (now that WinFX stuff is a “core” part of .Net). It’s funny how I spend a good part of my development time customizing built-in ASP.Net controls to do what I want them to do and not do what they were designed to do.

My three biggest complaints with ASP.Net, in no particular order…

Naming containers. I understand why, but they make it almost impossible to write client-side JavaScript code. Microsoft’s answer to that is to register your scripts in codebehind and reference “ClientID” properties, but that is hardly a programming solution.
The insistence on formatting with TABLEs (which is finally being addressed with the CSS adapters).
The single-form limtation of ASP.Net, the dependency on ViewState, and the whole rely-on-postback model (which translates fine to some applications but terribly to others).
The general goal of not expecting developers to write code. I want to write code — I want to control my application. Enhanced ASP.Net controls (things like GridViews) should be add-ons, much like you buy a component library from a company like ComponentArt (whose WebUI suite I use often). Microsoft can make them if it wants to, but don’t force-feed it on everyone.

Yeah I know that was four, but I’m a bit peeved by Microsoft today.