The Basics of Creating Server Controls
page 4 of 7
by Justin Lovell
Average Rating: 
Views (Total / Last 10 Days): 52060/ 93

Guidelines and Trends for Developing Controls

Before we can begin at looking at some code for creating server controls, I have added a few guidelines and trends for developing server controls. Note that I am not calling it rules; although I would like to. These are just some general guidelines and trends and I am not including every single one here because of the following reasons.

  • I am bound to forget to mention every single guideline or trend.

  • No one will remember all the rules for later on in the series.

  • I do not want to reference back to this article later in the series.

Without further a due, here is the general guidelines and trends:

The control class should be able to be inherited from

Whoever wants to extend your control, should be freely able to do so. No matter who your target audience is or what functionality and features that your control provides, you will always find that one developer who will want to extend it for his/her own extra mile.

The most common scenario is that the developer wants to create a control that they do not want to do common, repetitive data binding for every page. Sure they can drop your server control into a user control and do their data binding there and use that across their pages... but do you really want to do that if you spent an investment of your time for a rich design time (and possibly, to mention your customers investment of money into your product). If your “clients” really wanted to steal your control and publish it as their own, they would have to be forced to do one of the two things:

  • Attach your assembly to their distribution of their control (that is that their control cannot go solo without the help from your control).

  • Reverse engineer the byte-code that .NET Framework assemblies.

Other partial reasons are discussed below.

Rather override the appropriate methods than to attach to events when inheriting a control.

If you care about performance, this is one “rule” that you must keep in mind. Basically, you are saving extra memory being consumed which events point to delegated methods in your code. Obviously, you can avoid this by overriding the method name that is associated with the desired event – your code will then be inline with the execution of the event.

But most all, you might want to dominate how your code is going to run. You might want to do some processing before the actual event is fired or you might even want to dictate if the control fires its event at all. In other words, it puts you in the god role that you have absolute power. If you want the event to fire, ensure that its base's method that is associated with the event is called.

If you create custom events, create virtual (or overridable) methods to be associated with the events

On your quest around the .NET SDK, you might have noticed for every event, there is a method that is associated with that event, namely, OnEventName. You will also notice that the method's visibility is “protected”. The only reason why the accessor is protected is because it is not for use outside the control – instead, it should be used by controls that derive from it. Remember to mark it virtual, so the previous guideline “Rather override the appropriate methods than to attach to events when inheriting a control” can be obeyed by other control developers.

If overriding a method that is associated with an event, ensure that you call the base's method

This is not a hard-enforced rule as such but more of a fore-warning. If you want the event to be fired, then the base's method that is associated with the event must be called. The explanation is in both of the previously discussed guidelines and trends.

Always do your processing during the PreRender event of the page life cycle – not during the Load event.

This must be declared as a golden rule. The page developer do their processing during the Load event. You, as the control developer, is to take those changes that the page developer possibly did to your control during the Load event and start processing. To ensure that no “concurrency” error of order of events will occur, the last event that any major changes that can be done is during the PreRender event – straight after the Load event. It is just a precaution, just in case the page developer creates a page framework that may throw your processing off.

If you need to do some processing before the PreRender event, you can consider doing processing during the Init event.

Deliver data to view state and to persist during post backs

Pretty simple trend and should become a rule because so many control developers do not follow this. The usual excuse is that the page developer should not be lazy by setting those few properties or that the page developer should populate the data every time the page is executed. This just breaks the normal flow of developing pages and some might want to keep their 233MHz SQL Server machine a bit “airy” from unwanted requests. Although a database server is hardly found on a low resource as that, that might as well be the resources available if a web farm gets a sudden influx of traffic.

If you, as the control developer, insist that the page developer caches the DataTable, you might lose a valuable customer. The reason why you will lose him is because he will see your workmanship as lazy. Do not be a lazy developer yourself.

Expose Properties, not fields

There is one sole reason for doing this – keeping consistency with the current OOP model of the .NET Framework. It will also offer you more flexibility to do some changes between two versions of your controls without breaking them.

As I said before, we will analyse other guidelines and trends as we deal with the subject when we are examining it under great detail.

View Entire Article

User Comments

Title: How do I put this control on a page?   
Name: G Shields
Date: 2010-07-21 11:53:01 PM
Okay, so I have the inherited custom control class. How do I put it in my page?
Title: Need a translator   
Name: Rob
Date: 2009-05-18 2:24:18 PM
Overall I found this article helpful, in some places though the English is so bad that it is practically illegible. As a result, I may have missed some of the finer points.
Title: Simply The Great   
Name: Dot Net Lover
Date: 2008-12-18 10:26:30 PM
An Excellent Article.
Thanx for writing.
10 out of 10.
Title: Spell check please   
Name: bszom
Date: 2007-05-23 4:33:57 AM
Lame-man's terms? Please, this article would be 3x as good had it been spell-checked.
Title: BRILLIANT explanations and structure!   
Name: Magnus B
Date: 2007-01-26 11:56:21 AM
Thank you for gathering what I need to know in such a professional and independent page. Just the way I would ;)
Title: Good work   
Name: Narendra S. Jakhotia
Date: 2006-11-07 4:50:52 AM
this topic Cleared most of my concepts on creating controls. I need help from U . I want to combine properties of Image button and Label please tell me how can I do it?
If possible please help me
Title: Excellent Example   
Name: Jayesh Chudasama
Date: 2006-09-01 2:22:23 AM
Great Example!! It outlines all basic needs to understand to create server control.
Title: The Basics of Creating Server Controls   
Name: Jan Waiz
Date: 2005-08-04 11:53:17 AM
Title: your history on classic ASP   
Name: JP
Date: 2005-08-03 3:42:12 AM
You history on Classic ASP is not quite right. Classic ASP supported use of functions and subroutines which allowed code to be placed anywhere in your page. It also supported use of code classes and window script components (WSC). WSC files are components in XML format which did not have to be registered on the server.

Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-02-25 6:50:51 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search