Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility

SharePoint v3 was the huge benefactor of the ASP.NET team taking the Web Part framework and adding it to the core ASP.NET 2.0. Since SharePoint is ~~not~~ now built on top of ASP.NET 2.0, it no longer has its own Web Part implementation... instead it completely relies on the ASP.NET 2.0 framework. Yes, there is a WebPart class in the SharePoint assemblies, but we are not supposed to use it as it is only there for backwards compatibility; it makes Web Parts built in WSS v2 / SPS 2003 work in WSS v3 / MOSS 2007. Instead we should always create ASP.NET 2.0 Web Parts for SharePoint and that is the official recommendation by Microsoft.

When building custom Web Parts, you always hear people say "don't use Render(), only use RenderContents() or use the more OO approach and implement CreateChildControls()." Personally I favor the latter approach of using CreateChildControls(). So why should you not use Render()? Because unbeknownst to you, you are actually breaking something quite powerful.

We all know the browser DOM... but did you know SharePoint has its own DOM? It is called the Web Part Page Services Component, aka WPSC (no, I didn't forget a 'P', don't ask me why there is only one in the acronym :)). I wrote about this in one of my two chapters I contributed to a WSS v3 dev book. Basically the WPSC provides developers with a SharePoint specific client-side DOM that allows developers to listen for events, interact with Web Parts and even set properties... all through script on the client. The WPSC is implemented using a bunch of client-side code. You can see a snippet of it if you look at the source of a SharePoint page... for example, here's the very end of the homepage of the SharePoint Conference 2008 page (implemented using MOSS 2007 WCM... wahoo!):

Click the image for more sizing options as this is
obviously quite small to see everything. :)

See all those varPartWPQ# variables? Those are pointing to a specific Web Part in a client-side object. Using this object you can get values from some public properties of the Web Part... very cool!

But wait... there's more! There are also two other properties you can use to get access to the rendered Web Part. First, take a look at how ASP.NET renders Web Parts:

Web Parts are rendered in an HTML <TABLE> with two rows, each row containing one cell (shown in red in the previous image). The top cell contains the header of the Web Part, the bottom cell contains a HTML <DIV> (shown in blue in the previous image) which contains the rendered Web Part. When SharePoint renders the page, it adds a unique ID to the HTML <TABLE> as well as a unique ID to the <DIV>... developers can use these ID's to get to the Web Part via client-side code. Great... so why did I just go through all that? Because when you use RenderContents() or CreateChildControls(), the rendered markup produced by those methods is put inside the <DIV>. If you override Render(), you are replacing the entire <TABLE>! Thus, by replacing the entire table, you are breaking the WPSC... the whole SharePoint specific DOM!

This is just one reason, albeit a big one, why we all say you should use RenderContents() or CreateChildControls()... you should never use Render() when creating Web Parts. Never never never use Render() (hey recruiters, this is a great interview question for prospective SharePoint developers)!

Let's switch gears and talk about accessibility. There are always those who believe table-based design is evil and pixel perfect design (ala CSS-based layout) is the way to go. I'm not stepping into that fray in this post. But let's take a look at the CSS based implementation. Some kits like the Accessibility Kit for SharePoint, a fantastic educational tool (note: it is not a turn-key solution), show how you can implement an accessible site using the CSS-layout approach. One thing they do is leverage control adapters to change the rendering of the stock ASP.NET 2.0 and SharePoint controls. However one that is missing is adapters for the Web Part and Web Part Zone controls.

Lots of people complain about this and go about building their own control adapter to replace the Web Part tables as CSS. That's all fine and good, but they are breaking the WPSC. Now... I fully acknowledge that not many people leverage the WPSC. Heck, I bet many people didn't even know it existed. If you elect to build your own control adapter to get rid of the HTML table, just know that you are implementing a solution to a problem, but by doing so, you are introducing a new problem. Granted, the new problem (a broken WPSC) may not outweigh the need for a CSS-based layout so it may be ok. Thus your mileage may very. At least you now know what you're doing.

Technorati Tags: sharepoint,moss,wss,web part

posted on Monday, February 18, 2008 11:50 AM

Feedback

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/18/2008 12:17 PM Madhur

Great post .. Agree with everything .. apart from the interview thing ..

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/18/2008 3:46 PM Sherman Woo

This is exactly what I had been thinking, but had been seeing examples all over the Internet overriding Render(). In fact, I had started a question on my blog about to ask, "what are people using?" My instincts said to use CreateChildControls() or RenderContents(). So I did... but still...

I cracked open some books:

1. Chapter 4 of "Inside WSS 3", Pattison/Larson writes about using CreateChildControls() and RenderContents() if necessary.

2. Chapter 10 of "Developer's Guide to WSS 3", Todd Bleeker says to override RenderContents().

3. Jan Tielens writes in Chapter 7 of "Real World SP2007" that one should use CreateChildControls() as well. (The first time I read this a while back, I got a bit confused b/c he has an example in there for overriding Render(), which is what I thought he suggested.)

So, there you go. Enough proof from the experts. Amazing what a few months away from the books will do; gives a bit of a fresh perpsective.

Time to delete that draft post...

- Sherm.

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/18/2008 3:50 PM AC [MVP MOSS]

Sherman-
So the #2 in your list... that is Bleeker's book, but what you read isn't from Bleeker. I wrote two of the three Web Part chapters in that book. :)

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/18/2008 5:29 PM Aaron Powell

Thanks for the post AC, I've always wondered where the HTML table structure was generated from in the web part rendering engine and now I know.

Time to bring on some control adapters to make the HTML a bit more light weight (I don't use the WPSC so I'm not concerned about breaking it).

And also, thanks for the link to the conference page, I've been looking for an example of a MOSS generated page with Web Parts that has the HTML of a MOSS page so I can have a look at how you'd do an advanced layout with MOSS.

Although I wish I could view the master page, would make reverse engineering a whole lot easier :P

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/18/2008 10:57 PM clayton

Hi AC

Very informative.

The link you provided
http://msdn2.microsoft.com/en-us/library/ms477066.aspx

states that WPSC only applies to web parts that derive from Microsoft.SharePoint.WebPartPages.WebPart and doesn't relate to System.Web.UI.WebControls.WebParts.WebPart.

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 6:02 AM Dirk

We have just spent ages removing any unnessisary table tags and replacing them with divs. But now we have to put back in the bloat back in?

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 11:02 AM Eric Shupps

Dirk,

I don't think that's what AC is saying. If the need for fully-compliant CSS design in your implementation overrides the need to leverage (now or in the future) the WPSC, then so be it - but at least you're making an educated decision. This way, when you do try to implement client-side code down the road, you'll know why it's not working and you can fix it on a case-by-case basis.

I would also add that our work in tracing server control performance has shown that overriding Render() can have strange effects on component processing in the page lifecycle. In effect, it "breaks" the defined inheritance model wherein the page inokes the web part Render() method from it's own implementation of RenderChildControls() - these calls are processed in a particular order and overriding Render() directly can have unexpected results. It's best to let the page handle that method on it's own and use a downstream method - such as RenderContents() or CreateChildControls() (I favor the former but that's just me) - to render the required output.

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 12:16 PM Frode Magnussen

I'm in the middle of reading Inside WSS 3 a second time, and this gave me a better understanding of using the CreateChildControls() and RenderContents() methods. Thanks AC.

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 2:58 PM JJ

I would feel much worse about ruining the SharePoint-specific DOM if the SharePoint-specific DOM was more useful.
Unfortunately WPSC appears to be unavailable in non-IE browsers, and anyone who's concerned about accessiblity is likely programming cross-browser as well.

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 3:38 PM Buzza

Whenever you override any method, you should always call its base class method, unless you know what that base class is doing and you know for a fact you done need that functionality.

So if this is done you would have an issue that you described above.

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/19/2008 4:04 PM AC [MVP MOSS]

Dirk-
Eric is spot on. I'm not saying you have to do it one way or the other... the point of this post was to simply educate you in what is going on when you remove all those tables for Web Parts. If you don't use the WPSC, or any products that leverage it, then is it really an issue for you? You could make the argument that it isn't.

re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/26/2008 5:33 AM Matthias Glubrecht

Hi Andrew,
that was an interesting post, mainly because I had never heard about WPSC before ;-)
As Clayton stated, according to http://msdn2.microsoft.com/en-us/library/ms477066.aspx the WPSC applies only to Parts derived from Microsoft.SharePoint.WebPartPages.WebPart.
Since this base class is only provided for backwards compatibility reasons (as you wrote), it seems to me that it is not a good idea to use WPSC at all and hence it wouldn't matter if you break it by overriding Render().
By the way, will Microsoft.SharePoint.WebPartPages.WebPart be removed in later versions of WSS? I can't really imagine that.
On the other hand I would suggest to _never_ override Render() for the sake of compliance with the framework.
For example, any accessibility enhancement could target the base classes used by SharePoint and I would expect it to change the complete page structure and thus also remove the TABLE layout surrounding Web Parts. Render() should be a private method of the WebPart class.
Any thoughts on the future of WPSC or Microsoft.SharePoint.WebPartPages.WebPart?
Regards, Matthias

# re: Understanding how Web Parts are rendered, why to never use Render() and a bit on accessibility 2/27/2008 11:55 AM AC [MVP MOSS]

Mathias-
This is true... only Web Parts that use the SharePoint Web Part class affect the WPSC, but you still shouldn't use Render() :)

WebParts, Micrososft and dreadful HTML 4/7/2008 9:40 AM Ric

While I take your point regarding breaking the WPSC, the basic fact remains that in this day and age and with the understand we all have about accessibility, there is absolutely no excuse for Microsoft to build the HTML the way they have. I am no MS basher, but they have consistently written truly dreadful client side code/markup; whether that be HTML, CSS or JavaScript (even their own JScript examples are stunningly poor).

In a test example recently, I dropped a web part (based on a ASCX) into a WebPartZone and it managed to generate 4 (yes, four) levels of nested tables. There is not a single justification that can be given for that.

Ric.

Post Feedback

Title:
Name:
Email:	(email will not be displayed)
Url:
Comments:
Please add 5 and 2 and type the answer here: Remember Me?

All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelivant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.

This work is licensed under a Creative Commons License
Site design by Heather Solomon.