SharePoint Blogs / SharePoint University
SharePoint Blogs and SharePoint University - all in one place!
Need SharePoint Training? Attend a SharePoint Bootcamp!

Please delete cookies related to sharepointblogs.com and sharepointu.com to resolve login issues!

Sharepoint WebPart Development and Sharepoint Portal Web Part Life Cycle

Hi,

Aside from enjoying the buzz of the upcoming new server version, I was reviewing my notes on Course 2014.

I have found in the notes something that I have really got confused myself several times, however, it was out there in the course-ware all the time...

Where do I put my code in a web part?

Seems easy at first right? o matter how easy it seems to be, i still find it challenging in many occasions.
So there is a  life cycle of a web part in the material,  but one should put this side-by-side with a regular asp.net server custom control life-cycle, because WebParts are essentially, Custom ASP.NET Controls at the end...

  • Instantiate : The constructor
  • Initialize : OnInit method and Init event
  • Load : OnLoad method and Load Event
    • (*) Raise Changed Events : IPostBackDataHandler, RaisePostDataChangedEvent method 
    • (*) Raise Postback Events : IPostBackEventHandler, RaisePostDataEvent method
  • PreRender : OnRender method, and PreRender event
  • Render: Render method
  • Unload: OnUnload method and Unload event
  • Dispose: Dispose method

Now, the “Render” is the most confusing word here, simply because there are way too many events and methods that has “Render” in it when you deal with System.Web.UI.Control class and it's ancestors, render this and render that, and it is not even the same as the traditional “Render“ concept :)

To make it directly to the point, if you are simply rendering HTML in a WebPart, don't get confused, and use RenderWebPart method... You will avoid messing up the skins and default benefits of inheriting from Microsoft.Sharepoint.WebPartPages.WebPart class...

But life is not that simple always, sometimes you want to use ASP.NET Server Controls (like a Grid), and benefit from the ASP.NET framework right :) Who wants to open and close table tags in literals? I don't... In fact, I try to avoid it as much as possible and use it with discretion...

If you think the same way, you should familiarize yourself with the whole ”ASP.NET Custom control development”, and I think a very good place to start is the “CreateChildControls” method...

A few clues :

  • Put the ASP.NET child controls as fields in your code
  • Instantiate, and add them to your page in CreateChildControls method override,
  • Attach the necessary event handlers in the same place.
  • If you need to refer them anywhere else in the code, make sure you call “EnsureChildControls“, :) to ensure that they are there

Then you won't worry about the post-back consequences and they will “charmingly“ work

Hope it Helps

Duray AKAR


Posted 05-24-2006 3:28 PM by Unclaimed Blog

Comments

Ramesh wrote re: Sharepoint WebPart Development and Sharepoint Portal Web Part Life Cycle
on 07-31-2007 1:05 PM

Can you please send a simple sample on the post-back issues?  Thanks.

Erinc Arikan wrote re: Sharepoint WebPart Development and Sharepoint Portal Web Part Life Cycle
on 10-24-2008 11:11 AM

But most of the time we need some kind of mechanism to differentiate between postbacks, because mostly we will have more than one postbacks in the same page. For instance a grid can have a filter that's initiated by button click, but at the same time it might have column sort event which might cause the postback. And plus there might be other web parts that cause post back events. So it seems to me viewstate can help us in those scenarios.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?
Need SharePoint Training? Attend a SharePoint Bootcamp!
Posts (c) their respective authors. Everything else (c) 2009 SharePoint Experts, Inc.