www.brettresources.net

Creating a asp:HyperlinkColumn for your DataList or Repeater

Brett Burch — 2004-05-07

The HyperlinkColumn is an effective way of generating a column of links for the DataGrid, but is not accessible in other templated ListControls such as the DataList or Repeater. There are several methods for adding this capability onto your web forms. I'll show 2 methods here.

The first is to use a standard anchor tag and the DataBinder.Eval method. You can use this method when you don't need the server control to quickly generate a link, which potentially reduces ViewState. Pass the data source, field, and format string into the DataBinder.Eval method on your web form. For example:

<a href='<%# DataBinder.Eval(Container.DataItem,"product_id" , "/product_detail.aspx?id={0}") %>'><img align="right" border="0" src='<%# DataBinder.Eval(Container.DataItem,"image_url_sm" , "/ShowImage.aspx?img={0}&w=150&h=150") %>'></a>

An advantage here is that you can specify whatever you wish as the display item for the link. In the example above, I set the href element of my anchor tag to the product_detail.aspx page, with my product_id from the database in the QueryString.You could set the display for the link as static text, or text from another database field, or in the sample above, a thumbnail with its source set in the same manner as the href of the anchor tag. The html generated from the above sample is shown below, for product 67 having an image url string "67_small.gif" in the database.

<a href='/product_detail.aspx?id=67'><img align="right" border="0" src='/ShowImage.aspx?img=67_small.gif&w=150&h=150' /></a>

A note of advice on this method
The DataBinder.Eval method can be costly because of late binding overhead. As quoted from ASPAlliance:

CAUTION:
Since this method is called at runtime, it can cause performance to noticeably slow compared to standard ASP.NET databinding syntax. Use this method judiciously, particularly when string formatting is not required.

DataBinder.Eval resources:

Another option is to simply return the url for the href element of an anchor tag via a public function in your code-behind class. When using this method, be sure to pass your url database field item as type object into the function. This simplifies dealing with NULL database values (passing a NULL as a string into your function will throw an exception). An example of this in use on an aspx page is shown with the returnUrl function below.

Click <a href='<%# returnUrl(Container.DataItem("product_id")) %>'>here</a> to view detail about this product.

The public function to return this information is:

Public Function returnURL(ByVal id As Object) As String
	If IsDBNull(id) Or (id Is String.Empty) Then
		Return ""
	Else
		Return "/product_detail.aspx?id=" & id  
	End If 
End Function

You could also set the NavigateUrl of a asp:Hyperlink item during the onItemDataBound event of the DataList. Use the e.Item.FindControl method to find your asp:Hyperlink and then set properties accordingly. I recommend avoiding this except when the server control is absolutely necessary. I am uncertain, however, of the advantages gained with this method, and therefore have not elaborated.

In summary, you can still easily have templated hyperlinks without the asp:HyperlinkColumn in your DataLists and Repeaters. The fastest and least expensive way to develop this capability is to use a simple old anchor tag and use either the DataBinder.Eval method or a public function to return strings to build the link.I am sure there are other methods as well that I have not mentioned. Test it out, and contact me with suggestions / comments.

An Overview of Web Application Architecture Best Practices

Brett Burch — 2004-07-20

#1, 3, 4, 5 and 8 have information that is pertinent only to .Net application development. However, the same basic generals apply, regardless of the underlying technology used.

Use a tiered architecture for your server-side code (C#, VB.Net, PHP, JSP, etc). Tiered architectures contain a business layer, data layer, and wrappers for either (or both). Separating the UI from the business layer can allow the same code to be used from different UI's, such as a database call returning a SqlDataReader to either a Web form or a Windows form. Separating the business logic from the data layer can allow code that returns the same data type to be re-used extensively.
De-couple each piece of the application as much as possible. Keep database code in the database (via stored procedures*), UI components on the web / windows forms, JavaScript in .js files, and style information in CSS files. Think of these different pieces of the application just as a data store (xml file, SQL Server, Oracle, MySql, etc), where the data exists separately from the web files. For example, database information cannot possibly be stored in a CSS file. In the same way I recommend CSS and JavaScript information should not be stored on the UI files.
* Due to the recent discussions about the actual performance gains of stored procedures, I am not recommending stored procedures for performance purposes, but as a way to store the database access information in the database and separately from web site files. Taking advantage of stored procedure permission control is also a great way to lock down and restrict data access.
Use server controls only where necessary, but don't under-use. There's no need to re-invent the wheel. The balance here can be the difference between fast and horribly slow pages. Check ViewState in a browser and try to keep this as small as possible. Turn off view state for items that don't change based on user interaction.
Implement a custom error page, and an application level error event to be notified of exceptions. Use these to email or log errors for QA and support purposes.
Database connection strings, secure information and static variables should be kept in the web.config file (or relevant j2ee config.xml file). Web.config cannot be served to a browser, and does not require a re-compile when changes are made. For example, a database server going down would require a re-compile of all applications using an Application level variable for a database connection string, set in the global.asax file. A web.config file simply requires the file to be re-saved (the web application has a listener on this file and restarts when changes are made).
Include style information for cross-browser support. For example, all tables should have cellpadding, cellspacing, and border set (even if 0). All elements with height of 100% should have the height attribute set, and on a style tag for that item. Images should always have height, width, and alt text set so they load separately from the page's text (speeding up the display to the browser).
Use div tags and style sheets to create navigation bars (and wherever else possible as well). Textual items are much less bandwidth-costly, and can be changed / updated easier faster than images.
Decide carefully when to bind data bound objects. Use the Page.IsPostBack property to avoid rebinding on each page viewing. On items that are bound with different data on each posting, reduce ViewState as much as possible to avoid storing the data in ViewState, only to bind with different data on the next PostBack.

Creating Web Parts for SharePoint Portal Server 2003 with ASP.Net User Controls

Brett Burch — 2004-08-12

Have you ever needed to create a server control, but found yourself having trouble rendering the HTML in traditional code-behind methods? Have you ever found yourself needing to create a Web Part for your Intranet but could not afford to take the time to test and debug a web part when HTML must be rendered on a line-by-line basis using the HtmlTextWriter? In a traditional web application, User Controls simplify the process of adding "snap-in" web page parts. I'll show you how to use these here with SharePoint Web Part development to drastically reduce Web Part development time.

Create a new Web Part Library VS.Net project. To get the Web Part Library template, go to MSDN page: SharePoint Products and Technologies Templates: Web Part Templates for Visual Studio .NET. For further directions, see MSDN page: Web Part Templates for Microsoft Visual Studio .NET. Add a separate CAB Setup and Deployment project to the solution with all the content, documentation and primary output from the web part library project. I named mine "WebParts" and the default namespace was thus "WebParts."
Create an additional VS.Net solution, first containing a Web Application project, such as http://devbox/yoursite. If you already have a VS.Net solution you wish to create your web parts with, this is not required.
Add a separate Web Application project to the solution created in step 2, which is a sub-folder of the existing project (ex: http://devbox/yoursite/web_parts). This ensures that each project in the solution has a separate /bin folder and will produce a unique .dll file. Use the second web project to create the user controls, which will act as your web part content, once deployed. Add a web form in this project to test. Be sure to not use Page.IsPostBack, because SharePoint pages post back more frequently than traditionally expected.
To work around this, I set the visible property of my container web control to "false" and checked for that in my user control's Page_Load event. When false, I knew the page had not yet posted back yet. I then set the visible property to "true" in my code-behind and continued from there. Specifically, I used a DataList. Every post back caused the DataList to be re-DataBound, so the only time I had to check to DataBind to the original data was when the visible property of my DataList was "false."
```
private void Page_Load(object sender, System.EventArgs e)
	{
		// Put user code to initialize the page here 
		//set DataList to invisible for starters... that will be
		//similar to testing PostBack, then set it to visible and bind			
		if (dlPages.Visible == false)
		{				
			dlPages.Visible = true;
				//...do any other setup tasks here as well
			BindDataList();
		}
	}
```
Also be certain that any web.config appSettings also are created in the Portal server's web.config file, because this is the location that your User Controls will look to for appSettings when deployed to the SharePoint server.
Create a folder on the Portal server to contain user controls (ex: \\sps2k3\c$\Inetpub\wwwroot\wpUserControls). Add the .ascx file from the second web project (created in step 2) in this folder. Add the .dll from the \bin folder of the second project to the \bin folder of the Portal (ex: \\sps2k3\c$\Inetpub\wwwroot\bin).
Use the web part library project (created in step 1) to render the user controls. For the code on how to do this, I highly recommend Fons Sonnemans' article titled "User Control Container Web Part". Rather than creating one individual user control container web part where SharePoint users select a user control to work with, I simply created an individual web part for each user control by setting the value of _userControl in the code. This is less flexible, but does allow more granular access to properties of each web part. Make sure that each web part has a .dwp, and that the Build Action property of that .dwp file is set to "Content."

Add each web part's information in the web part library's manifest.xml file, as shown below. Note that the first SafeControl element is the WebParts namespace. This is the root namespace for all the created web parts in this project. Each individual web part's declaration follows.

<?xml version="1.0"?>
<!-- You need only one manifest per CAB project for Web Part Deployment.-->
<!-- This manifest file can have multiple assembly nodes.-->
<WebPartManifest xmlns="http://schemas.microsoft.com/WebPart/v2/Manifest">
  <Assemblies>
    <Assembly FileName="WebParts.dll">
	<!-- Use the <ClassResource> tag to specify resources like image files or JScript files that your Web Parts use. -->
    <!-- Note that you must use relative paths when specifying resource files. -->
      <!--
      <ClassResources>
        <ClassResource FileName="Resource.jpg"/>
      </ClassResources>
      -->
      <SafeControls>
        <SafeControl Namespace="WebParts" TypeName="*" />      
        <SafeControl Namespace="webpart1_uc" TypeName="*" />
        <SafeControl Namespace="webpart2_uc" TypeName="*" />
        ...
      </SafeControls>
    </Assembly>
  </Assemblies>
  <DwpFiles>     
    <DwpFile FileName="webpart1_uc.dwp"/>
    <DwpFile FileName="webpart2_uc.dwp"/>
    ...
  </DwpFiles>
</WebPartManifest>

Build the Web Part Library project.
Copy the Cab file created in the previous step over to the Sharepoint server's IIS 6.0 \bin folder (ex: \\sps2k3t\c$\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN).

On the Portal server, use stsadm.exe from the command prompt to install the web part package, where webpartcab.cab is the name of the file just copied over:

C:\Documents and Settings\Administrator>cd c:\program files\common files\microsoft shared\web server extensions\60\bin

C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN>stsadm.exe -o addwppack -filename webpartcab.cab -force

webpartcab.cab: Deploying to http://sps2k3/.
Operation completed successfully.

You can now use your Web Parts on your SharePoint site.

Notes

Any re-build of the user control requires the second web project's .dll to be re-copied over, as well as the .ascx file, but only if that was also modified. However, this does NOT require the web parts to be re-deployed as well because the user control's "container" has not changed. This simplifies the process of debugging and deploying fixes because you can test your changes in a UI sandbox environment on your web site before deploying. The exception to this is when you need to test SharePoint specific functionality, such as reading a file collection within your SharePoint site. When you have finished your QA process, the .dll just needs to be copied over to your folder on the Portal server that contains user controls (ex: \\sps2k3\c$\Inetpub\wwwroot\wpUserControls) as mentioned above.

This article does not mention using strong named assemblies, which may be more desirable when working with SharePoint, as Full Trust scenarios, and security in general, are dealt with in a much stricter manner. This will be discussed in a future article.

Additional Resources

Injection-Safe Inline SQL with LIKE in the WHERE Clause

Brett Burch — 2004-10-19

This is something that might be obvious, but I thought I would mention this because it wasn't obvious to me. As I have mentioned earlier, I prefer stored procedures, but recently found myself in a scenario where I had to use inline SQL. I will avoid the "why" discussion and get to the point. I wanted to use the '%partial_term%' wildcard syntax in order to retrieve partial matches on a search page (so that FName, First_Name, Name, nameF, etc. would all be returned when inputting "name", for example). To prevent SQL Injection, however, I wasn't about to just use string concatenation for my search term. Googling for an example using inline SqlParameters with = (EQUALS operand) in the WHERE clause gets you what you need, but I couldn't find an example with LIKE in the WHERE clause.

The Solution

Add the % wildcard(s) before / after the partial search string when creating the SqlParameter object. The example below lives in an object helper class and uses a function in my DAL class (which acts more or less like a wrapper around the Data Access Application Block for .Net).

string sql = "SELECT <columns> FROM <table>";
if (search_string != string.Empty)
{
	sql += " WHERE <column> LIKE @searchstring";
	SqlParameter[] sqlParams = new SqlParameter[1];
	sqlParams[0] = new SqlParameter("@searchstring","%" + search_string + "%");
	return DAL.GetDataTableWithText(sql,sqlParams);
}
else
{
	return DAL.GetDataTableWithText(sql,null);
}

Handling the Client-Side onblur event of an asp:TextBox wth Server-Side code

Brett Burch — 2004-12-10

A recent project required me to handle more client-side events than the usual click, onchange and submit events that are easily wired up with the .Net framework. Here's a way to handle additional client-side events with server-side code. WARNING: This does involve what I would consider a hack, but does solve the business problem.

What I had to do was add a button to the page, and then wire up an event (as usual) for that button's click event. This is as easy as drag, drop, and double-click in Visual Studio. To display this, I have added an aspx web form to a project called "testing.aspx"... Here is my .cs code:

public class testing : System.Web.UI.Page
	{
		protected System.Web.UI.WebControls.TextBox txt1;
		protected System.Web.UI.WebControls.Button btnBlur;
	
		private void Page_Load(object sender, System.EventArgs e)
		{
			// Put user code to initialize the page here
			string eventHandler = this.GetPostBackEventReference(this.btnBlur, ""); 
			this.txt1.Attributes.Add("onblur",eventHandler);
		}

		private void btnBlur_Click(object sender, System.EventArgs e)
		{
			Response.Write("btnBlur_Click fired from txt1's onblur event.  I can do anything server-side here.");
		}
		
		//the rest of your code-behind class
		...
				
		private void InitializeComponent()
		{    
			this.btnBlur.Click += new System.EventHandler(this.btnBlur_Click);
		}

What we have essentially done in the above code is hijack the button's server-side Click event. This is dangerous, because if the button were to be displayed, clicking it would cause our asp:TextBox's onblur server-side code to run. We would obviously not want that to happen. The best way I have found to prevent the button from being clicked is to hide it from our users. I set the Visible property of my button (btnBlur) to False, and additionally wrapped it in a div HTML element with a style tag on the div including "display:none" just to be safe. Call it paranoia, since the Visible="False" on the asp:Button tag will prevent it from being rendered on the form, but I felt it important to include. The critical piece of my testing.aspx code is below.

<asp:TextBox Runat="server" ID="txt1"></asp:TextBox>
<div style="display:none"><asp:Button ID="btnBlur" Text="" Runat="server" Visible="False"></asp:Button></div>

Exiting your asp:Textbox now will cause server-side code to fire.

Taking It a Step Further
So what if we want to do this in a DataList, DataGrid, or Repeater? Not a problem. My business requirement led me to use a DataList. Our asp:Button's click event is going to get bubbled to the DataList's ItemCommand event. Some sample DataList code shows how we set this up.

<asp:DataList Runat="server" ...
	<ItemTemplate>
		<!-- txt onblur stuff -->
		<asp:TextBox Runat="server" ID="txt1" Width="225px"></asp:TextBox>
		<div style="display:none"><asp:Button ID="btnBlur" CommandName="Blur" Text="" Runat="server" Visible="False"></asp:Button></div>
		<!-- end txt onblur stuff -->
	</ItemTemplate>

This is no different than the previous snippet, except that we don't explicitly set up a Click event for the Button. Instead, we set a CommandName for the Button, which we can use in the DataList's ItemCommand event. To see this, review the code below.

private void DataList_ItemDataBound(object sender, System.Web.UI.WebControls.DataListItemEventArgs e)
{
	if (e.Item.ItemType == ListItemType.Item ||
		e.Item.ItemType == ListItemType.AlternatingItem)
	{
		// the next 4 lines are required to handle the textbox's onblur event with server-side code...
		Button btn = (Button)e.Item.FindControl("btnBlur");
		string eventHandler = this.GetPostBackEventReference(btn, "");
		TextBox txt = (TextBox)e.Item.FindControl("txt1");
		txt.Attributes.Add("onblur",eventHandler);
		//end onblur code
	}
}

private void DataList_ItemCommand(object source, System.Web.UI.WebControls.DataListCommandEventArgs e)
{
	switch (e.CommandName)
	{
		case "Blur":
			//do whatever you like here to handle the onblur event
			break;
	...

As you can see, I used the ItemDataBound event of the DataList to set up the onblur hijack rather that Page_Load. This is because the TextBox lives in a different place in the Page's control tree (and is more easily accessible here). As you can also see, setting up the code to handle our Blur command is just like setting up any othe DataList command. Hopefully this helps others in future endeavors. It stands to reason that any JavaScript event could be handled in this way.

My question is, will future ASP.Net controls have this functionality built-in? Just for experimentation purposes, I think I'll create a server control that is capable of handling any client-side event for an HTML input control. More about that later...

Using the new ASP.Net 2.0 XmlDataSource

Brett Burch — 2006-02-04

I previously used a custom collection to display the article titles and summaries on my /dotnet landing page. This involved reading the XML file, hydrating a business object for each article, returning the business object to the page, explicitly setting the data source for the DataList, and finally calling DataBind for the DataList. Since I had my XSD schema I was able to use xsd.exe and generate the business object, but the whole process still required quite a bit of code. Just the business object hydration (upgraded to the .Net 2.0 version using a Generic implementation) might include code like the following:

public List<ArticleType> GetAllArticles()
{
    this.ValidateUrls();
 
    List<ArticleType> articles = new List<ArticleType>();
 
    XmlTextReader xtr = null;
    try
    {
        xtr = new XmlTextReader(this.XmlDataFileUrl);
        xtr.MoveToContent();
 
        //read the file
        while (xtr.Read())
        {
            if (xtr.LocalName == "article" && xtr.NodeType == XmlNodeType.Element)
            {
                xtr.Read();
                //move past the article element to id
                while (xtr.NodeType != XmlNodeType.Element)
                {
                    xtr.Read();
                }
                //get the id value
                ArticleType article = new ArticleType();
                article.id = xtr.ReadString();
 
                //move to date text element
                while (xtr.NodeType != XmlNodeType.Element)
                {
                    xtr.Read();
                }
                article.date = Convert.ToDateTime(xtr.ReadString());
                article.dateSpecified = true;
                xtr.Read();
                //move to title text element
                while (xtr.NodeType != XmlNodeType.Element)
                {
                    xtr.Read();
                }
                article.title = xtr.ReadString();
                xtr.Read();
                //move to description text element
                while (xtr.NodeType != XmlNodeType.Element)
                {
                    xtr.Read();
                }
                article.description = xtr.ReadString();
                xtr.Read();
                //move to content text element
                while (xtr.NodeType != XmlNodeType.Element)
                {
                    xtr.Read();
                }
                article.content = xtr.ReadString();
 
                articles.Add(article);
            }
        }
    }           
    finally
    {
        xtr.Close();
    }
    return articles;
}

Since my data's original source is XML, it seemed silly to translate the XML to an in-memory object when I could bind the DataList directly to the XML file. I didn't mind not having to write the code either... So how do we use the XmlDataSource? Simply specify a URL where the data comes from, a URL for any XSLT transformation, and the XPath query to grab the records of choice from the data file. For example:

<asp:XmlDataSource ID="xds" runat="server" DataFile="~/xml/articles.xml" TransformFile="~/xml/articles_adapter.xsl" XPath="Articles/article"></asp:XmlDataSource>

Note that due to the fact that my XSD schema defines the properties of each article as an element rather than an attribute, I transform the data coming from http://www.brettresources.net/xml/articles.xml so that for each article, the elements are transformed to attributes. The transformation is shown below.

<?xml version="1.0" encoding="utf-8"?>
 
<xsl:stylesheet version="1.0" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:brett="http://www.brettresources.net/xml/articles.xsd">
 
  <xsl:template match="/">
    <Articles>
      <xsl:for-each select="brett:Articles/brett:article">
        <article>
          <xsl:attribute name="id">
            <xsl:value-of select="./brett:id"/>
          </xsl:attribute>
          <xsl:attribute name="date">
            <xsl:value-of select="./brett:date"/>
          </xsl:attribute>
          <xsl:attribute name="title">
            <xsl:value-of select="./brett:title"/>
          </xsl:attribute>
          <xsl:attribute name="description">
            <xsl:value-of select="./brett:description"/>
          </xsl:attribute>        
        </article>
      </xsl:for-each>
    </Articles>
  </xsl:template>
 
</xsl:stylesheet>

Finally we get to our XPath query. I use "Articles/article" because I'm pulling back all the articles in the file.

Let's discuss the syntax to actually display this data in the DataList. Instead of using the Container.DataItem methodology, such as

<%# DataBinder.Eval(Container.DataItem, "date", "{0:d}") %>

(shown with a format string), we use a new XPath function call. For example,

<%# XPath("@id", "/dotnet/article.aspx?id={0}")%>

(shown again with a format string). Note the @ symbol in front of the attribute name, as this is XPath syntax for an attribute. My DataList now has a DataSourceId attribute with the ID of the XmlDataSource associated with it. The ItemTemplate now looks like the following:

<asp:DataList ID="dlArticles" runat="server" DataSourceID="xds">
    <ItemTemplate>
        <a href="<%# XPath("@id","/dotnet/article.aspx?id={0}")%>" title="<%# XPath("@title")%>"><%# XPath("@title")%></a>
        <p><%# XPath("@description")%></p>
    </ItemTemplate>

This by no means reduces the necessity for business objects when doing CRUD functions with your data, obviously, but this is a nice and easy way to present XML in ASP.Net 2.0 applications. It's also worth noting that caching comes out of the box with the XmlDataSource, so that's additional code which you don't have to write.

I really like what I see so far from ASP.Net 2.0 so far. The amount of code we as developers have to write to present data in applications has been greatly reduced, and this is just one example.

Additional Resources

A Quick Exploration of the Atlas UpdatePanel control

Brett Burch — 2006-02-09

I've been messing around with Atlas a bit and think the Update Panel server control is what I'm looking forward to most. This article is a brief introduction to the Update Panel control, and only touches the most basic aspects of the Update Panel and Atlas.

Essentially I want to show how easy it was for me to set up an AJAX enabled page that swaps UserControls in a Placeholder control by clicking a LinkButton. The sample shows a prototype that could be built into a tabbed (Yahoo-esque?) interface for viewing data about a customer by your favorite customer service representative. The actual web form itself is very simple. The code below shows the web form.

<form id="form1" runat="server">
    <div>
        <atlas:ScriptManager runat="server" ID="ScriptManager1" EnablePartialRendering="true" />
 
        <atlas:UpdatePanel runat="server" ID="UpdatePanel1">
            <ContentTemplate>
                <uc1:TabbedAccountDashboard ID="TabbedAccountDashboard1" runat="server" />
            </ContentTemplate>            
        </atlas:UpdatePanel>    
    </div>
</form>

The only code on the actual page of relevance is the Update Panel which has my "Sales Dashboard" user control in it and the ScriptManager server control, which adds the Atlas JavaScript file references to the HTML output delivered to the browser.

The User Control itself contains the "tabs" and the content-swapping code. There are a set of LinkButtons on the top which would become the tabs. A placeholder below is the container for the UserControls which are then swapped out based on the currently viewed tab.

<div id="primary-nav">
    <ul>
        <li id="acctsum"><asp:LinkButton runat="server" ID="lbAccountSummary" CommandArgument="AccountSummary.ascx" Text="Account Summary" OnClick="lbAccountSummary_Click"></asp:LinkButton></li>
        <li>&nbsp;|&nbsp;</li>
        <li id="act"><asp:LinkButton runat="server" ID="lbActivities" CommandArgument="Activities.ascx" Text="Activities" OnClick="lbActivities_Click"></asp:LinkButton></li>
        <li>&nbsp;|&nbsp;</li>
        <li id="notes"><asp:LinkButton runat="server" ID="lbNotes" CommandArgument="Notes.ascx" Text="Notes" OnClick="lbNotes_Click"></asp:LinkButton></li>
        <li>&nbsp;|&nbsp;</li>
        <li id="tix"><asp:LinkButton runat="server" ID="lbTickets" CommandArgument="Tickets.ascx" Text="Tickets" OnClick="lbTickets_Click"></asp:LinkButton></li>
    </ul>
</div>
...
<div style="padding:3px;">
    <asp:PlaceHolder ID="placeholder" runat="server"></asp:PlaceHolder>   
</div>

I use the LinkButton CommandArgument property to declare the UserControl of choice to render in the Placeholder. The server-side events that are called when a user clicks a LinkButton are shown below.

public partial class dotnet_atlas_TabbedAccountDashboard : System.Web.UI.UserControl
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!this.IsPostBack) this.LoadPlaceholderWithContent("AccountSummary.ascx");
    }
 
    protected void lbAccountSummary_Click(object sender, EventArgs e)
    {
        this.LoadPlaceholderWithContent(((LinkButton)sender).CommandArgument);
    }
 
    protected void lbActivities_Click(object sender, EventArgs e)
    {
        this.LoadPlaceholderWithContent(((LinkButton)sender).CommandArgument);
    }
 
    protected void lbNotes_Click(object sender, EventArgs e)
    {
        this.LoadPlaceholderWithContent(((LinkButton)sender).CommandArgument);
    }
 
    protected void lbTickets_Click(object sender, EventArgs e)
    {
        this.LoadPlaceholderWithContent(((LinkButton)sender).CommandArgument);
    }
 
    /// <summary>
    /// 
    /// </summary>
    /// <param name="SenderCommandArgument"></param>
    private void LoadPlaceholderWithContent(string SenderCommandArgument)
    {
        Control ctrl = this.LoadControl(SenderCommandArgument);
        this.placeholder.Controls.Add(ctrl);
    }
}

All the above code can be written and executed on the server, but the client does not have to PostBack and refresh the entire page in order to be updated. To compare the difference, view the side-by-side comparison. The content user controls merely contain static HTML in this example, so the performance difference is negligible. If, however, there was code in each of the User Controls that queried a database and dynamically generated their content, the difference would be quite noticeable to the end user.

Testing Custom Server Control Code That Depends On Its Container / Parent (the Page Object)

Brett Burch — 2006-03-05

The issue of faking the Page object cropped up recently for me when building a server control library. I added client-side event attributes to my controls and wanted to write a test that essentially verified the expected html had been added to the HttpResponse. I hit a roadblock when I got object reference errors for the control's Page object. Note that I am not simply testing ASP.Net API - I will gladly give the ASP.Net team the credit they deserve and regard their API as capable code. I wanted to test scenarios that were intertwined with that code, however. Verifying a client-side event name in a collection was added or removed from both the Attributes collection and my custom collection, or verifying what the Attributes collection contained are examples. To explain, consider the following code, where I attempt to add an Attribute to a TextBox control, which ultimately invokes a PostBack to be handled server-side:

if (string.IsNullOrEmpty(this.Attributes[ClientSideEvent]))
{
    string eventHandler = this.Page.ClientScript.GetPostBackEventReference(this, eventArgPrefix + ClientSideEvent, false);
    this.Attributes.Add(ClientSideEvent, eventHandler);
}

Calling this code from NUnit will throw an error for the Page object when trying to get the PostBackEventReference string. The first and arguably easiest way to skirt this is to simply check whether this.Page is null. Temporarily shelving the KISS principle, I'll continue the discussion. Looking at the second code sample shows that I have extracted the implementation of retrieving the eventHandler string.

private string GetPostBackEventReference(string ClientSideEvent)
{
    string ret_val = "";
 
    if ((this.Page == null) || 
        (this.Page.Form == null))
    {
        ret_val = eventArgPrefix + ClientSideEvent;
    }
    else
    {
        ret_val = this.Page.ClientScript.GetPostBackEventReference(this, eventArgPrefix + ClientSideEvent, false);
    }
 
    return ret_val;
}

This is all well and good, but what about when checking for if the current browser supports JavaScript? The ASP.Net 2.0 method for performing this check is no longer checking Browser.JavaScript. If you try to build your server control solution using Browser.JavaScript, you'll notice this property is now deprecated. Clicking to the definition of this property gets you the following:

[Obsolete("The recommended alternative is the EcmaScriptVersion property. A Major version value greater than or equal to 1 implies JavaScript support. http://go.microsoft.com/fwlink/?linkid=14202")]
 public bool JavaScript { get; }

So then, now we have to do something like the following:

private Boolean BrowserSupportsJavascript
{
    get
    {
        if (this.Context != null &&
            this.Context.Request != null &&
            this.Context.Request.Browser != null &&
            this.Context.Request.Browser.EcmaScriptVersion != null)
        {
            return (this.Context.Request.Browser.EcmaScriptVersion.Major >= 1);
        }
        else
        {
            //for testing...
            return true;
        }
    }
}

That looks like a lot of fun! This no longer seems the simplest solution, so we can throw those KISS principles out the window. Can we just assume that if the Page or Context object exists, then all of its properties and sub-properties are going to be there for us? My assumption is yes, but assuming doesn't sound like the best solution. After all, I want to write a test as the skeptical code-tester, right? I'd like to mention now that it is a shame the Page.VerifyRenderingInServerForm or comparable method does not return a Boolean. Not only that, but it would also be much appreciated if the ClientScriptManager class would implement an interface I could create a test helper from. So what are our better options? I decided that it may be best to add an isTest private flag to check when dealing with these scenarios. The GetPostBackEventReference function now looks like:

private bool isTest = false;

private string GetPostBackEventReference(string ClientSideEvent)
{
    string ret_val = "";
 
    if (this.isTest)
    {
        ret_val = eventArgPrefix + ClientSideEvent;
    }
    else
    {
        ret_val = this.Page.ClientScript.GetPostBackEventReference(this, eventArgPrefix + ClientSideEvent, false);
    }
 
    return ret_val;
}

If this isTest flag is private, then I'll need to set it via Reflection in my unit test, and hope that nobody using my control library messes with it. The unit test SetUp code then becomes:

private const BindingFlags bindingFlags = BindingFlags.Instance | BindingFlags.NonPublic;

private ClientSideMadnessTextBox ctrl;
 
[SetUp]
public void SetUp()
{
    ctrl = new ClientSideMadnessTextBox();
    typeof(ClientSideMadnessTextBox).GetField("isTest", bindingFlags).SetValue(ctrl, true);
 
    ...
}

You could take this a step further if you liked and have a utility class which contains all the methods you need to fake (such as GetPostBackEventReference or GetWebResourceUrl), pass a type to this utility class, and then use reflection to call the method on the type specified (be it MyClientScriptManager or the real ClientScriptManager) but you would still be dependent upon the isTest private member, so this seems overly complex. Just a thought, though...

Has anyone else come across this? This looks like a Dependency Injection scenario to me, and I'm wondering what others have done. Surely the ASP.Net team tests their code, so I'm curious how they did this. Any advice is appreciated.

Additional Resources

PrivateObject Unit Tester