Web parts, an essential element in displaying information within the Sharepoint environment, have a life cycle containing four essential events. The stages or events are called OnInit, CreateChildControls, OnPreRender and Render. These events load, compose, compile and present the content of a Web part to the end user.
- OnInit: This method handles initialization of the control. event used to create controls of web part, Configuration values set using WebBrowsable properties and those in web part task pane are loaded into the web part.
- LoadViewState – The view state of the web part is populated over here
- OnLoad: This event handles the Load event. This is also used for initialize the control but is not intended for loading data or other processing functionality.
- CreateChildControls:This is the most popular event in web part life cycle. This creates any child controls. So if you are adding any control to display then you have to write in this method. All the controls specified are created and added to controls collection. When the page is being rendered for the first time the method generally occurs after the OnLoad() event. In case of postback, it is called before the OnLoad() event. We can make use of EnsureChildControls() – It checks to see if the CreateChildControls method has yet been called, and if it has not, calls it.
- RenderWebPart The WebPart class calls this method to render (that is, create) the HTML that the Web Part will display.
- Note If you’ve ever written ASP.NET custom controls that aren’t Web Parts, you’re probably accustomed to overriding the Render method rather than the RenderWebPart method. In a Web Part, however, the Render method creates only the chrome (the Web Part’s title bar and border, for example). The RenderWebPart method creates the HTML that appears in the body of the Web Part.
- RenderChildren method, you should know that every ASP.NET page, user control, and custom control has a Controls collection. This collection contains an object for each element the page or control will display. When you’re working with ASP.NET pages or user controls, ASP.NET loads the Controls collection from the .aspx or .ascx file as follows: Because custom controls (and therefore Web Parts) have no .aspx or .ascx file, the Controls collection is initially empty. You can A single call to the RenderChildren method will then tell each control, in order, to emit its HTML. If you use code such as the above to create five paragraph controls, RenderChildren would write five sets of <p> and </p> tags, each with the content you assigned.
The choice between using output.Write and RenderChildren is entirely yours. The output.Write method is easier to see and understand. Loading up the Controls collection and calling RenderChildren is more abstract, but it helps modularize your program and it guards against invalid HTML.
Although there’s nothing wrong with output.Write, the examples in this book will use the RenderChildren method exclusively.
- EnsureChildControls: This method ensures that CreateChildControls has executed.
EnsureChildControls method must be called to prevent null reference exceptions. This method ensures that the CreateChildControls method has finished executing. If not, it waits for that method to complete. This avoids the embarrassing moments that occur when a method tries to manipulate an object that CreateChildControls hasn’t created yet.
- SaveViewState: View state of the web part saved.
- OnPreRender: This method handles or initiates tasks such as data loading that must complete before the control can render.
- Page.PreRenderComplete: The page fires the PreRenderComplete event after all controls have completed their OnPreRender methods.
- Render: This method is used to render everything.
- RenderContents: Renders the contents of the control only, inside of the outer tags and style properties.
- OnUnload: Performs the final cleanup. Dispose
Page_Load normally fires when ASP.NET finishes loading the page’s server controls into memory. In a Web Part, however, ASP.NET doesn’t load the server controls; your own CreateChildControls method does that. So, you may as well put your code in the CreateChildControls method, or call it from within that method.
Within a Page_Load event handler, programmers normally use the IsPostBack property to differentiate between the initial display of a page and a subsequent submission. But in the case of Web Parts, a postback also occurs when a team member uses a browser to add, remove, or reconfigure any Web Part on the page.
This makes sense if you stop and think about it. There are many times—such as when you use a browser to add a Web Part to a page—when a round trip to the server clearly occurs. However, these aren’t normal form submissions, and you shouldn’t process any data that form fields might contain.