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.
Improved testability. The source code should include unit tests.
Improved rendering. Wherever possible, the code generated should be improved.
Improved configuration. There's limited configuration options right now unless you change the source code.
Improved documentation. The typical need of an open source project.
With these things in mind, and after some experimentation using a simple control (CheckBoxList), I came up with a few ideas...
Improving Configuration
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:
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!
Improving Testability
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:
Generate HTML markup
Apply WebForms-specific scripts (such as Page.ClientScript.RegisterForEventValidation(checkList.UniqueID)).
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
-> CSSFriendlyAdapter<T>
.OnPreRender()
-> CreateHtmlRenderer(); [abstract]
<- HtmlRenderer<T>
.RenderBeginTag()
-> _renderer.RenderBeginTag();
.RenderContents()
-> _renderer.RenderContents();
.RenderEndTag()
-> _renderer.RenderEndTag();
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.
[TestFixture]
public class CheckboxListHtmlRendererTests
{
private StringWriter stringwriter;
private HtmlTextWriter htmlwriter;
[SetUp]
public void SetUp()
{
stringwriter = new StringWriter();
htmlwriter = new HtmlTextWriter(stringwriter);
}
[Test]
public void TestValidHtml()
{
CheckBoxList control = new CheckBoxList();
control.ID = "test";
CheckBoxListHtmlRenderer renderer = new CheckBoxListHtmlRenderer(control);
Assert.AreEqual(renderer.RenderBeginTag(htmlwriter),
"<ul class=\"AspNet-CheckBoxList AspNet-CheckBoxList-RepeatDirection-Vertical\" id=\"test\">\r\n");
}
}
Cool stuff.
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
a control.
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?
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.
Jose
Please remember to click "Mark as Answer" on the post that helps you, and to click "Mark as Not Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
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. :(
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.
Peace,
JD
John Dunagan
President - SW Florida .Net Developers Group
http://www.swfldev.net
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.
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.
I plan on switching to either Google Code or Assembla, because I think both are superior to CodePlex. Probably will go with Google Code + a Google Group.
What's in a name... The logical idea is CSSFriendly2. But are these really "CSS Friendly" adapters, or adapters that render proper, customizable semantic markup for ASP.Net web controls? I say the latter. The intent of the adapters isn't to make them CSS
friendly, but markup friendly. WebControlAdapters is a very simple, but descriptive, name, as is AspNetAdapters (has the added benefit of "AspNet" in the name).
Initially we will tackle some very simple controls to flesh out a coding, configuration, and documentation methodology. My test code used the CheckBoxList, which is a good example of a simple control that can use some markup-friendly adapting.
As much as I'd like to say .Net 3.5, there's really no reason to, because from a web control standpoint there is little changed between 2.0 and 3.5, and there is a huge installed base of 2.0 framework apps that would benefit from the project. No need to
exclude them for the sake of the latest and greatest.
C# only. I wouldn't even suggest someone try to maintain a simultaneous VB.Net version. The intent is not to give sample code but to give a working, binary drop-in solution that adds well-documented functionality.
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...)
I'm in, and I'm good with all of that. 2.0 adapters should work in 3.5, anyway. But I'll warn you - my GUI-fu far outstrips my C# or my javascript. In fact, I came at this from GUI, when I was about to choke some developers. I'm calmer now, and ready to
(help) code.
John Dunagan
President - SW Florida .Net Developers Group
http://www.swfldev.net
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.
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
GUI approach.
Still lots to do before this is consumable by others, but I wanted to get this up and hosted.
bdemarzo
Member
435 Points
168 Posts
Thoughts on version 2 of these adapters
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...
Improving Configuration
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:
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!
Improving Testability
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
-> CSSFriendlyAdapter<T>
.OnPreRender()
-> CreateHtmlRenderer(); [abstract]
<- HtmlRenderer<T>
.RenderBeginTag()
-> _renderer.RenderBeginTag();
.RenderContents()
-> _renderer.RenderContents();
.RenderEndTag()
-> _renderer.RenderEndTag();
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.
Cool stuff.
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 a control.
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?
css adapters
- blog: www.sidesofmarch.com
JSantaMaria
Participant
751 Points
147 Posts
Re: Thoughts on version 2 of these adapters
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.
Please remember to click "Mark as Answer" on the post that helps you, and to click "Mark as Not Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
bdemarzo
Member
435 Points
168 Posts
Re: Thoughts on version 2 of these adapters
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. :(
- blog: www.sidesofmarch.com
JDunagan
Member
9 Points
3 Posts
Re: Thoughts on version 2 of 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.
Peace,
JD
President - SW Florida .Net Developers Group
http://www.swfldev.net
aezzell
Member
10 Points
8 Posts
Re: Thoughts on version 2 of these adapters
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.
bdemarzo
Member
435 Points
168 Posts
Re: Thoughts on version 2 of these adapters
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...)
- blog: www.sidesofmarch.com
JDunagan
Member
9 Points
3 Posts
Re: Thoughts on version 2 of these adapters
Oct 01, 2008 04:20 AM|LINK
I'm in, and I'm good with all of that. 2.0 adapters should work in 3.5, anyway. But I'll warn you - my GUI-fu far outstrips my C# or my javascript. In fact, I came at this from GUI, when I was about to choke some developers. I'm calmer now, and ready to (help) code.
President - SW Florida .Net Developers Group
http://www.swfldev.net
bdemarzo
Member
435 Points
168 Posts
Re: Thoughts on version 2 of these adapters
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: http://code.google.com/p/aspnetcontroladapters/
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 http://code.google.com/p/aspnetcontroladapters/wiki/CheckBoxList.
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 GUI approach.
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.
- blog: www.sidesofmarch.com
aezzell
Member
10 Points
8 Posts
Re: Thoughts on version 2 of these adapters
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 ;-)
bdemarzo
Member
435 Points
168 Posts
Re: Thoughts on version 2 of these adapters
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: http://code.google.com/p/aspnetcontroladapters/wiki/CheckBoxList
- blog: www.sidesofmarch.com