What would you say to someone who wants to make everything a .NET control?

Question

For example, we have some CSS rules to define our form layout. We use the following markup:

<div class="foo">
    <label class="bar req">Name<em>*</em></label>
    <span>
     <asp:TextBox runat="server"/>
            <label>First</label>
    </span>
    <span>
     <asp:TextBox runat="server"/>
            <label>Last</label>
    </span>
    <div class="clear"></div>
</div>

In my opinion, this is perfectly fine markup. Following these rules is not a burden since you're supposed to worry about clean, correct markup anyway. It's being suggested that we "enforce" these rules with a control that looks something like the following:

<x:FormField runat="server" Label="Name" Required="True">
    <x:TextBox runat="server" hint="First"/>
    <x:TextBox runat="server" hint="Last"/>
</x:FormField>

My instinct tells me that XHTML markup is our friend, not our enemy. Two questions:

1. Am I completely off base to resist making all these custom controls just to emit markup?
2. If you agree with me, what reasons would you give?

Answer 1

I vote use the controls, because if that markup ever changed (say you wanted to add some nice jQueryUI effects to the boxes or add a RequiredFieldValidator control) you can make the change in one place and be done with it. DRY.

Answer 2

"Enforcing" a look-and-feel through CSS costs a lot less in time, support, maintenance and gray hair. There is nothing inherently more "enforcing" about composite controls (which is what your second snippet looks like.) There is, however, a lot more work involved in custom controls.

Bottom Line: Custom controls are about reuse and redistribution, not layout.

Answer 3

I can side with you on this one based on personal experience with this exact example. It may not apply as much for other scenarios, but label+textbox deserve to stay separate. Usually everything is fine until you get about 2/3 through the project and other people start to critically review it. My experience was that users/managers/ui designers wanted exceptions in many places - different spacing, an extra something between the label and the textbox, etc. Also keep in mind validation routines and one validator does not fit all sizes in ASP.NET. By the time you get a working control like this to handle all the different scenarios, it probably would have been less work to just keep label+textbox on the forms.

Answer 4

I do something similar. Take that to the extreme, where you have 30-40 controls like this on a page. Having controls that take care of labels, validators, etc for you make your life a lot easier.

We also have automated form helpers that can load form values onto an object and vice-versa, to alleviate all the

lefthand = righthand code all over the place.

Answer 5

Against the controls:

• Performance numbers. Measure a baseline XHTML page and the same page with 20 controls on it that emit the same markup. This would give you an estimate.
• Additional cost. You need to factor out the cost of developing, testing and maintaining these controls.

For the controls:

• Consistency. You now have a single place to control the XHTML structure with all elements you need and it'll stay consistent across all pages.
• Regression. You can have the proper unit and scenario testing to ensure your XHTML structure is what you require it to be.
• Reuse. You can reuse the same control in other projects in future.

Answer 6

Using a custom control may be a good choice if you intend to re-use the code, or if you wish to define custome properties or attributes on the code, but it makes little sense otherwise.

Answer 7

I would say "Don't become an abstraction astronaut" aka "Architecture Astronaut"

Further reading: http://www.joelonsoftware.com/articles/fog0000000018.html

Answer 8

I agree with Franci... there are good reasons for using controls like that. However, don't take it to the extreme. If you're being told that everything should be a control and compiled in a separate file, then someone is enforcing a policy blindly and without using common sense. Policies are only good if they are applicable. Applying policies (or coding patterns) in situations where it doesn't apply usually results in a nightmare down the road.

Others have said that already, but the reason why I'm bothering to answer here is to point out one special thing. If you are a junior developer and have a senior person telling you to do things a certain way - you do it that way. There is a possibility that they know about requirements you don't know about, or something about the environment that they aren't telling you. There are many times when I've told a junior developer "just do it this way" without a lot of explanation why - because we just need to get it done, and giving them a programming lesson is something I don't have time for. I will usually go back and explain to them later, but when a project is behind schedule (and they always are), you do what you're told and argue about it later.

Answer 9

I'd say it depends on how much the control gets used and is it just in one project or do you need to distro this amongst other projects? And whats wrong with a user control? You get the reusability + you still have markup