Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

ASP.Net controls

I've been going through a book on ASP.Net and have been playing with some basic Web Forms stuff, and here's something I'm kind of confused about: HTML server controls
vs. ASP controls. Now, I understand that the latter is basically a superset of the former, they are more powerful,
more type-safe, etc. Here's a question, though:
when would one rather use HTML controls (with runat=server) and not ASP controls ?  Can you suggest any
basic guidance rules - like "do use HTML controls when..." ?

I believe I found one aspect where HTML controls are better - if you want to have a client-side event handler.
That is, you can write:

<input type=button id=btn1 value="Click me"
  onserverclick=SvrClick
  onclick="alert('Hi from JavaScript');"  runat=server>

I don't believe you can do this with asp:button. But I am
probably wrong.

Mike
Monday, December 09, 2002

Mike you're absolutely right about that last one. That's exactly why I occasionally use the <input type=submit runat=server> instead of <asp:Button runat=server>.

Other than that, the API for the WebControls is much more consistent that HtmlControls. Rule of thumb: use WebControls, just use HtmlControls wherever necessary.

Duncan Smart
Monday, December 09, 2002

Thanks for reassuring me. Two questions though:

a) Can you point me to where this is clearly stated ? The book that I have is silent about it, just as the internet tutorials I've seen so far.

b) Is this the only advantage HTML controls have over ASP ones ?

Mike
Monday, December 09, 2002

Don't trust me? :-) then:
http://msdn.microsoft.com/msdnmag/issues/01/09/asp/default.aspx

"Is this the only advantage HTML controls have over ASP ones" -- what? a better API an consistency? Well, yes. In the main part, HtmlControls are there so you can simply do a runat=server for ANY tag. Plus round-tripping to non-ASP.NET aware HTML editing tools might work better.

WebControls really win it for me when you have something like:
<asp:DropDownList ID="_fruitList" runat="server">
  <asp:ListItem Value="1">Apple</asp:ListItem>
  <asp:ListItem Value="2">Banana</asp:ListItem>
  <asp:ListItem Value="3">Pear</asp:ListItem>
</asp:DropDownList>

and then decide that a bunch of option buttons would be better - I just change the tag:

<asp:RadioButtonList ID="_fruitList" runat="server">
  <asp:ListItem Value="1">Apple</asp:ListItem>
  <asp:ListItem Value="2">Banana</asp:ListItem>
  <asp:ListItem Value="3">Pear</asp:ListItem>
</asp:RadioButtonList>

...the API to both is pretty much identical so no code change.

Contrast this to the HTML equivalent:
<select id="_fruitList" runat=server>
  <option value="1" selected>Apple</option>
  <option value="2">Banana</option>
  <option value="1">Pear</option>
</select>

and:

<input type=radio value="1" runat=server ID="_fruitRadio1" NAME="FruitGroup">Apple<br>
<input type=radio value="2" runat=server ID="_fruitRadio2" NAME="FruitGroup">Banana<br>
<input type=radio value="3" runat=server ID="_fruitRadio3" NAME="FruitGroup">Pear<br>

yuk - you can imagine how ugly the code will be to retrieve the selected item from radio buttons - and how it would differ greatly from the <select>.

Duncan Smart
Monday, December 09, 2002

One mildly good reason to use HTML Server controls is if you're  migrating an existing ASP page and need to do it quickly...just add the runat=Server attribute to your existing code.

Mike Gunderloy
Monday, December 09, 2002

Thanks for the link.

>"Is this the only advantage HTML controls have over ASP
>ones" -- what? a better API an consistency?

Sorry I apparently didn't make myself clear - what I meant to ask was whether the ability to have both server- and client-side event handlers was the only advantage that
HTML controls had over ASP controls (not the other way around).

So, the rule seems to be "Use ASP server controls whenever you can, except when you need client-side event
handlers and/or - according to Mike Gunderloy - just want a quick port of the existing ASP
code to ASP.Net.

Mike
Monday, December 09, 2002

Oh, and in fact you *can* have both client and server event processing on an ASP.NET Web Server control. The trick is that you need to add the client event dynamically in code after the control has been instantiated. Here's a simple example:

1. Place a Button control (Button1) and a TextBox control (TextBox1) on a new Web Form.
2. Add this code behind the form:

    Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        If Not IsPostBack Then
            Button1.Attributes.Add("onclick", "alert('Hi from JavaScript');")
        End If
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        TextBox1.Text = "Filled in on the server"
    End Sub

3. Run the form. Click the button. You'll see the client-side event execute, then the form will post back, then the server-side event will execute when the form returns.

Mike Gunderloy
Monday, December 09, 2002

Thanks Mike, this proves that my doubts had some ground.
I find it rather strange though that there's no design-time
support for client-side events - I mean, how difficult would
it be to allow something along the lines of

<asp:button ..... onserverclick="ServerSideClick"
onclientclick="alert('hi there');">

- especially since just about any button in real life does
some client-side JavaScript anyway ?

So, the bottom line is that there's really no reason to prefer
HTML controls to ASP controls (other than the quick ASP-to-dot-net conversion).

Mike
Monday, December 09, 2002

Or...

namespace MyWebControls
{
  public class Button : System.Web.UI.WebControls.Button
  {
      public string OnClientClick
      {
        get { return Attributes["onClick"]; }
        set { Attributes["onClick"] = value; }
      }
  }
}

...
<%@Register TagPrefix="my" Namespace="MyWebControls" Assembly="MyWebControls" %>
...
<my:Button OnClientClick="alert('hello');" Text="Click me" runat="server" />

Duncan Smart
Wednesday, December 11, 2002

I'd add to this that the html control interface smells a bit more like DHTML DOM.

For example, the WEB control's textbox control has a Text property, while the HTML control running as a server control has a Value property.

Both of these properties represent the text that'll appear on the button once rendered in the browser.

This makes it a little easier to understand and make the conversion to ASP.NET for web developers that have mostly been working with the DHTML object model of browsers and relying on some other way of generating HTML server-side like ASP/PHP.

Consider the following code:

        'Text1 is an HTML control running at the server
        Text1.Value = "Yada yada"
        'TextBox1 is a WEB form control
        TextBox1.Text = "Yada yada"
        'Also consider the following radio button code:
        'Radio1 is an HTML control running at the server representing a radio button
        If Radio1.Checked = True Then
            Radio1.Value = "0"
        End If
        'RadioButton1 is a web form radio control and doesn't have avalue property without us assigning it one
        If RadioButton1.Checked = True Then
            RadioButton1.Attributes.Add("Value", "0")
        End If

In short, yes they webform controls have a more complete object model that looks a lot like it's VB-Form counterpart and makes it easy for VB developers to acces the functionality of HTML controls.

In the same fasion, server based HTML controls try to use the same obejct model developers use when writing client-side scripts around the DHTML object model.

Johan Myburgh
Tuesday, December 17, 2002

*  Recent Topics

*  Fog Creek Home