Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Wrapping Web Controls in a SharePoint Web Part : Page 2

With so many useful ASP.NET Web controls available, you should be able to use them in SharePoint, right? Well, you can. This article presents two ways to wrap existing Web controls in a SharePoint Web Part.


advertisement
Adding the Control to the Tree
Sometimes, you will require a slightly more complicated approach; however, it may affect debugging. The alternative to rendering the control into the output is to add the Web control as a child control to the Web Part. This is something that Web controls do all the time—draw themselves from a series of inner controls. For example, a data grid renders as a set of label, table, and hyperlink controls arranged in a way that makes sense.

Ultimately, this process is more complicated and harder to debug. It's more difficult to trap errors because you have less control over the way SharePoint (or more accurately, ASP.NET) draws the underlying controls. If one of the underlying Web controls being used in your Web Part throws an exception, that exception may percolate back up to SharePoint. SharePoint will respond by displaying a general-purpose error message that will do little, if anything, to help you understand what happened or where it occurred.

However, the upside is that the underlying Web control that you're using will be connected to the page so it can determine what kind of browser the client is using, and can fire events. Many developers have tried the Render method of rendering their controls only to find that there was something missing.

For example, if the Web control you're adding needs an event to fire that the Render method doesn't support, such as Prerender, if it needs to be able to inspect the browser that's calling it so it can determine how to write client-side JavaScript, or if there are events which need to fire for the control based on user input, you can find yourself out of luck—or more likely, confused as to the nature of the problem. Adding a control to the control tree avoids such negative scenarios.

Moreover, adding the control to the control tree is as easy, if not easier, than rendering the output of the control; however, there are differences. To add a control to the control tree, you make changes to the constructor of the object, as in the following AddTree method.

public AddTree() { System.Data.SqlClient.SqlConnection mySQLConnect = new SqlConnection(connectionString); mySQLConnect.Open(); SqlCommand myCmd = new SqlCommand(sqlString, mySQLConnect); System.Data.SqlClient.SqlDataAdapter myAdapter = new SqlDataAdapter(myCmd); DataSet ds = new DataSet(); myAdapter.Fill(ds, "Data"); DataGrid dg = new DataGrid(); dg.DataSource = ds.Tables[0]; dg.DataBind(); Controls.Add(dg); }

Note that the code in the AddTree method is not that different in structure from the code in the RenderWebPart method shown earlier. In both methods most of the code sets up the DataGrid for display, but AddTree adds the control to the control tree (by calling the Controls.Add method in the last line) rather than sending the rendered output directly as in RenderWebPart.

The other difference is that in RenderWebPart, the code is in the RenderWebPart method, which receives an HtmlTextWriter argument, whereas AddTree places the code directly in the constructor for the Web Part. In AddTree, you don't need to call the RenderControl method because that would override .NET's normal control processing and prevent the control from displaying. Conversely, the RenderWebPart method didn't have a constructor for the Web Part because all its work takes place through methods.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap