Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Feb 27, 2009 01:10 PM by bdemarzo
Sep 17, 2008 02:33 AM|LINK
I've been thinking about what can be done as part of a version 2.0 rewrite of the CSS adapters, and over the past few nights did some test coding to see what works and what doesn't.
First, let me outline some of the things that I feel should be a key part of version 2.0.
With these things in mind, and after some experimentation using a simple control (CheckBoxList), I came up with a few ideas...
The obvious choice is to use the web.config file, but what should be allowed in the configuration? The first obvious choice is CSS class names. For example, consider the following mock configuration:
Note the <CSSFriendly> configuration section, which includes a <CheckBoxList /> element that allows you to edit the generated CSS classes. Say you don't want the default? You can specify this as a configuration:
<CSSFriendly> <CheckBoxList cssClass="checkbox" disabledCssClass="disabled"
In this case, you have new class names. An attribute that is blank (itemCssClass) would not get a class applied. In the CheckBoxList case, the repeatDirectionCssClass would append the repeat direction of the control. Or something like that... Remember, this is just a first concept!
There are two ways to test web controls: to look at the HTML code they generate, or to do user behavior testing (possibly automated using something like Selenium). The latter is complex, but the former is not -- if you can somehow extract the HTML code generated by an adapter.
Unfortunately, this is easier said than done, so I started thinking about a new approach, which became a different way to look at how the adapters worked.
The adapters really do two things:
My thinking is to split the HTML generation out of the adapter by deriving everything from two abstract classes: CssFriendlyAdapter<T> and HtmlRenderer<T>. (In both cases, T is a WebControl.)
The CssFriendlyAdapter would have an abstract method, CreateHtmlRenderer(). That method would be responsible for creating an HtmlRenderer for the adapter. The HtmlRenderer is responsible for making the HTML markup for a given WebControl; the adapter serves as a wrapper around its renderer, and can still apply WebForms extras.
This improves testability because we can now test our HtmlRenderer classes to ensure they generate the expected HTML markup for a given control. Since the HtmlRenderer is easy to instantiate and has limited dependencies, it is easy to do so.
The flow looks something like this:
WebControl as T
-> CreateHtmlRenderer(); [abstract]
HtmlRenderer -- renders basic HTML
CssAdapter -- adds WebForms specific features
The following code is a sample of an NUnit test that actually works in my current sandbox.
public class CheckboxListHtmlRendererTests
private StringWriter stringwriter;
private HtmlTextWriter htmlwriter;
public void SetUp()
stringwriter = new StringWriter();
htmlwriter = new HtmlTextWriter(stringwriter);
public void TestValidHtml()
CheckBoxList control = new CheckBoxList();
control.ID = "test";
CheckBoxListHtmlRenderer renderer = new CheckBoxListHtmlRenderer(control);
"<ul class=\"AspNet-CheckBoxList AspNet-CheckBoxList-RepeatDirection-Vertical\" id=\"test\">\r\n");
Improved Rendering and Documentation
Obviously, any effort in rewriting the controls should include both improving the rendered HTML and the available documentation. For the latter, my idea is to document as we go, and provide a matrix for each adapter that illustrates what features work for
Documentation is something that, if done early and continuously, is easier to manage. Note that when I say "documentation" I am thinking moreso of API documentation and
implementation documentation -- that is, how an adapter will change markup and what control properties are supported by it.
Not sure when I'll have something for public consumption -- at this point, I am just experimenting with one control (CheckBoxList) before moving to more complex objects.
Comments? Feedback? Anyone interested in contributing?
Sep 23, 2008 09:13 PM|LINK
Althought I haven't have that much experience with the Adapter (I downloaded it about a year ago, couldn't get it to work with my exisiting project, so I gave up on it) but now that I'm in the process of building a new and improved version of my project
from scratch targeting .NET 3.5, I decided to give them a try. They work as I expected them to do,so I'm happy so far [:D]
I wish I could tell you if what you mention is needed, but I do have to agree that there needs to be more documentation. Hell, I might even try to write some custom controls myself. I definitely like the idea of <CSSFriendly>
inside the web.config.
Sep 29, 2008 01:04 AM|LINK
Documentation is definitely a big thing that's missing.
Since this post (and
a similar post on my blog) there have been only two replies -- one here (yours) and one on my blog. That's not much of an endorsing need to rewrite these adapters. :(
Sep 30, 2008 08:43 PM|LINK
Let me wholeheartedly add a third(?) request for a comprehensive rewrite of the CSS-Friendly control adapters.
I would recommend starting with the following: extend the improved rendering behavior to more controls.
It's kind of a death spiral the way it is now - the default set only renders three controls, developers give up on it because they'd have to write the renderers for all the other ones they want, they give up and lose interest, no feedback, no impetus to
innovate, the default set only renders three controls, lather, rinse, repeat.
If a large code base is out there, it's much easier for developers to tweak (and to submit fixes for stuff that doesn't quite satisfy). Doc is also easier than core dev.
My current woodie is for the wizards to render as divs and not tables. I'm happy that with the community build, there is framework to go by when 'rolling your own.' And when I do, I'll push it up.
That said, here beginneth the rant:
But even more than the default rendering, even in ASP.Net 3.5, and even finessing my game for IE6, which sucks tailpipes as a browser (and they're going to roll it out to Windows Mobile 7??), the thing that frosts my ^&%$! tips about Microsoft is the poor
attitude and the apathy they show toward people who want to make VStudio render better. Even ScottGu sends people to this pack when they ask the "why don't it div?" question - and that was back in 2.0, and NOTHING'S CHANGED in 3.5. No one gives a $#!+ until
they actually have to work it. That above anything else is why anybody in GUI who's seen anything else spits on .Net development. You think Ruby renders table tags? WTF is this, 1994?
Here endeth the rant.
I'll be back when I can do up a set of wizard controls to add to the stack. Thanks for listening.
Oct 01, 2008 02:49 AM|LINK
As someone who only recently (as in, this past April) started learning ASP.NET--while trying to head up the expansion of our corporate site from <300 to >600 pages (it seemed liked such a good idea at the time...)...
I wholeheartedly support the drive for documentation. I managed to get the menu adapter working in both a vertical & a horizontal layout, but it was tough.
Of course, a big part of the problem was my newness to ASP.NET, but judging by the number of posts I found from people having the same problems I was having, there must be a lot of newbies out there trying to use these things.
The one other issue I had with the menu adapter was that it didn't handle &s correctly. Fortunately, I found a post by someone who had a fix for it, and was able to decipher his C# code to make the necessary changes to the VB version that I was using.
It's a great tool, though--I'm really happy to have found it.
Oct 01, 2008 03:27 AM|LINK
OK, so I guess there's at least enough interest to make an effort worth trying.
My thinking is to create a separate project for the next version. In fact, I'm wondering if they should get a different name entirely. Random thoughts on the matter follow.
So, for those who care, let me know what you think, and if you want to contribute to the effort, let me know.
(BTW -- I was reminded how important this project can be when I recently started a new project to beautify an ASP.Net web site for a new client... and was reminded how TABLE tags are added around things where they shouldn't be. Ugh...)
Oct 01, 2008 04:20 AM|LINK
Oct 05, 2008 03:36 AM|LINK
I am proud to announce the new project: ASP.Net Control Adapers!
The project site is hosted through Google Code:
I have checked in my original test code, cleaned up a bit to make it more useful. It implements limited support for the CheckBoxList control. Source code includes the main project, a UnitTests project (using NUnit), a WebTests project (a web app that invokes
the adapted control in a web page), license/readme files, and an NAnt build script.
I also started working on a documentation format, which you can see at
There's still a lot missing in terms of implementation (not even postback support yet!), and unit testing, but in general the programmers out there should be able to understand the approach I'm taking, and designers/front-end developers can understand the
Still lots to do before this is consumable by others, but I wanted to get this up and hosted.
Also -- there's a Google Group for it:
http://groups.google.com/group/aspnetcontroladapters -- be sure to head there to add to the discussion.
Oct 05, 2008 04:58 PM|LINK
Great news! Can't wait until this gets its Big Girl Panties on and is ready to be used by those of us who had to Google NUnit and NAnt ;-)
Oct 07, 2008 04:55 PM|LINK
For those following along, I just made some changes and implemented more support for CheckBoxLists.
Take a look at the implementation notes here: