Should it be a user control or a server control?

You must have heard this question in the developer community or in online forums, or at least at your work place. Though, the concept of user and server controls in .NET is pretty old, some developers still get confused when it comes to making a choice between both of them. I myself used to go wrong with the selection and would pick one over the other, mainly because of a very thin line (ok ok..I heard you..a little thick) between them.

Up until now, I was fond of using UserControl for all of my projects. The ratio of picking a user control over server control always used to be somewhere close to 10:1 (probabilistically, 1.0 to 0.1) for me. However, it was then when I received a comment for my experimental work on Code Project article MultiSelect Dropdown Control about my decision being an unthoughtful over choosing a UserControl as the parent class, I decided to enlighten myself more about both the control types and find out why I feel it a thin line what is a very clear distinction, and why I fail to take their design guidelines into account when it comes to authoring them.

I believe one of the important reasons to go for a user control is its simplistic nature. It can be created as easily as a web page and Its design time development support for authoring makes things a lot easier. We don’t need to override the Render() method as we get out-of-the-box support for rendering. A user control is more suitable choice when target control is composite (a collection of other intrinsic controls) in nature and has a lot of static data. On the downside, it is less convenient for advanced scenarios due to its tight coupling with the application it is built for. If the same user control needs to be used in more than one application, it introduces redundancy and maintenance problems as its source form (.ascx) needs be copied and its reference must be provided on the hosting web page. We don’t get to see this kind of problem while dealing with server controls. A server control can be a best choice in the following scenarios:

• Redistributable
• Dynamically generated content
  
• zero maintenance ― single DLL which can also be added in the GAC
• Support to add the control in Visual Studio Toolbox.

A server control helps reduce redundancy as it is only a single DLL which can very easily be consumed in more than one application. According to Microsoft Support

"A server control is more suited for when an application requires dynamic content to be displayed; can be reused across an application, for example, for a data bound table control with dynamic rows”

Server controls provide full design-time support when used in a design-time host. It can be added to the toolbox of a visual designer and dragged and dropped onto a page. However, I believe the biggest disadvantage of using a server control is that, it requires to be written from the scratch for which one has to have a good understanding of page lifecycle and the order in which events execute which is normally taken care of in user controls.

Now, coming back to the title of my post "what should we choose", a user control or a server control? I would say such a decision should be a thoughtful one. If you want rapid application development (RAD) with full design time support without understanding the page life cycle, user control is the way to go. On the other hand, If ease of deployment with no redundancy and maintenance headaches is more important for you, think about custom server control.

HTH,

Creating User Controls ― a few good practices

In my previous post, Dealing with GAC atrocities, I talked about code reusability being an important aspect of rapid application development (RAD). User Controls in .NET support code reusability out of the box. Just to remind ourselves, a user control is a control that is created using the same technique we use for creating ASP.NET web pages. We create user controls every now and then in our everyday programming and, at times, we forget to entertain some of its important aspects during the development. For example exposing properties that define its behavior and layout , taking care of the situation where a web page can have multiple instances of a user control etc.

As you probably know that I love to follow the guidelines and like to stick to the checklist whenever possible. I decided to create one for myself containing good practices for user control development. The idea is to come back to this list to see what should go in the user control and what should not. Though, these are not industry standard best practices, I find them very useful in most of the scenarios. Please have a look and let me know what do you have to say about it. Moreover, If there is anything, a procedure, a guideline or even a practice that you think helps you in anyway while writing a user control and saves your time, share it with the world in the comments below.

1. Every single behavior of a user control should be represented by a public property. More the properties it has, the more it is customizable for the end user. I never forget to write properties that define the important characteristics of my list-type control e.g. AutoPostBack.

Private _AutoPostback As Boolean
  Public Property AutoPostback() As Boolean
      Get
          Return _AutoPostback
      End Get
      Set(ByVal value As Boolean)
          _AutoPostback = value
      End Set
  End Property

  Private _AllowParentSelect As Boolean
  Public Property AllowParentSelect() As Boolean
      Get
          Return _AllowParentSelect
      End Get
      Set(ByVal value As Boolean)
          _AllowParentSelect = value
      End Set
  End Property



2. There will always be only one instance of a user control on a web page is a blind assumption. If the user control looks good and is designed to keep the user friendliness and intuitiveness in mind, people would love to use it than once, sometimes on the same page which might lead to a conflict between their child control IDs. To deal with it, ClientID property can be used in the HTML as well as in the back end.

If AutoPostback = True AndAlso Request.Form("__EVENTTARGET") IsNot _
              Nothing AndAlso Request.Form("__EVENTTARGET").Equals(Me.ClientID + "_categoryMenu") Then

                  RaiseEvent OnSelectedIndexChanged(Me, Nothing)

              End If



3. All the external script files (JavaScript etc.) should always be registered using Page.ClientScript.RegisterClientScriptInclude and Page.ClientScript.IsClientScriptIncludeRegistered method to avoid registering duplicate scripts resources for multiple instances of user control on a page.

Private Sub RegisterClientScriptIncludes()

      Dim clientScriptMgr As ClientScriptManager = Me.Page.ClientScript

      If clientScriptMgr.IsClientScriptIncludeRegistered(Me.GetType(), "mcDropdown") = False Then
          clientScriptMgr.RegisterClientScriptInclude(Me.GetType(), "mcDropdown", ClientScriptIncludePath)
      End If

  End Sub



4. The user control should have no knowledge (no hard-coding), unless required, of any project/application-wide configurations e.g. resource (image/script) file path, connection strings, database column names of the supplied data source, default values etc. We can maintain the abstractness of a control by passing all these values from the page as properties.
   

Private _DropdownListStyles As String
  Public Property DropdownListStyles() As String
      Get
          Return _DropdownListStyles
      End Get
      Set(ByVal value As String)
          _DropdownListStyles = value
      End Set
  End Property

  Private _DataTextField As String
  Public Property DataTextField() As String
      Get
          Return _DataTextField
      End Get
      Set(ByVal value As String)
          _DataTextField = value
      End Set
  End Property

  Private _DataValueField As String
  Public Property DataValueField() As String
      Get
          Return _DataValueField
      End Get
      Set(ByVal value As String)
          _DataValueField = value
      End Set
  End Property



5. There is a possibility of a user control being used on a page which does not contain any .NET default server control, hence no sign of __doPostBack JavaScript function definition which can be a serious problem if the user control has to do a PostBack. We can harness GetPostBackEventReference() under ClientScriptManager which returns a string that can be used in a client event to cause Postback to the server.


6. There is a consistency in the property names e.g. DataSource, DataTextField, DataValueField for all ASP.NET data bound controls because of their support to the standard Windows Forms data-binding model. This helps developers gain familiarity with the control very quickly. We can try wherever possible to maintain this level of friendliness in our user control as well by keeping the property and method names as close to that of default controls. The same goes for event names as well. For example for a user control that is going to behave like a list-type control, we can think of having properties such as DataTextField, DataValueField, DataSource, SelectedIndex etc. and events like SelectedIndexChanged.

Private Sub ddlApplicationStatus_SelectedIndexChanged(ByVal sender As Object, ByVal e As System.EventArgs) _
                                          Handles ddlApplicationStatus.OnSelectedIndexChanged
      Try

          Dim ctlDropdown As mcDropdown = CType(sender, mcDropdown)
          Dim selectedVal As Integer = ctlDropdown.SelectedValue
          Dim selectedText As String = ctlDropdown.SelectedText

      Catch ex As Exception
          'log exception here...
      End Try

  End Sub



7. In addition to method and events, a list-type user control should also expose ListItemCollection that gives complete control of the items and facilitates adding, inserting, removing and finding items.


8. We need to make sure the control is able to maintain its state on PostBacks. It goes in line with the best practice of loading controls when the page is being rendered for the first time.

 If Not Me.IsPostBack Then
              InitializeUserControls()
          End If



9. Instead of inheriting our control class directly from System.Web.UI.UserControl class every time, we should first look for an abstract class if it is available that defines the same properties, methods, and events common that we need for our user control. For example ListControl class can be served as the abstract class for all list-type controls and DataBoundControl class for the controls that display their data in list of tabular form.


10. The default values should be specified for the control properties, hence allowing the user to get the control up and running in very little time.

Private _AllowParentSelect As Boolean
  Public Property AllowParentSelect() As Boolean
      Get
          Return _AllowParentSelect
      End Get
      Set(ByVal value As Boolean)
          _AllowParentSelect = value
      End Set
  End Property

HTH,

Ajax based multiselect dropdown control

As the saying goes.."a picture is worth a thousand words". Checkout the pictures below and download control if you like.

Collapsed View-1:

Expanded View-1:

Expanded View-2:

Click here download the control.

MultiSelect Dropdown Control

For an Ajax-based Multiselect dropdown, please visit this link

It’s an easy to use and lightweight control. The code is also fairly simple to understand. I have developed it using .NET and C# on the server side and JavaScript for client side scripting. Although it’s not a full blown web server control, it does provide with some useful features that help users in displaying and managing information on the page easily. Following is a small list of those features... Read More