Non-visual Controls are not just Components

Stephen Walther writes on TheServerSide.net:

Since it is part of the essential nature of a control to have a visual representation, the SqlDataSource is ill-conceived. Really, the SqlDataSource control should have been implemented as a component and not as a control.

I disagree, and given this design was something I was responsible for, I thought I should go ahead and share my own opinion. A little history first: This approach was actually first taken back in the Web Matrix days (when the VS model was based on DataSet components). We didn't have code-behind support and so, when we first introduced DataSource objects, the only choice we had was to implement them as controls. As we got the model working, we saw some rather compelling benefits to the declarative model, and so it seemed fit to continue building on it.

But more than just working around a limitation, fundamentally, I see controls like SqlDataSource as more than just mere components. They are controls in the sense that they participate in the page lifecycle, even though they don't offer a visual rendering. For example, data source controls manage view state, listen to OnInit, and LoadComplete events on the page to detect changes in parameter values etc.

The same is true of other non-visual controls. For example, the WebPartManager does something interesting in a whole bunch of control and page lifecycle events, and does in fact render script into the generated markup. Furthermore, it is in fact the parent control for all the WebParts on the page regardless of which zone they appear in!

Sure, one could invent a mechanism to allow components participate in the page lifecycle (which I personally think we should do... v-next perhaps). What I will agree to is that the design-time support for non-visual controls is somewhat lacking. All you can do today is toggle the visibility of non-visual controls. The complete idea behind non-visual controls was that dragging/dropping from the toolbox one would add it to the head of the page and not the body, and that any control in the head would automatically show up in the component tray, but that vision was not fully realized this time around.

Daniel Cazzulino has strongly argued for the component tray to be re-instated for some time now. I fully agree with him there; not necessarily for the sake of dropping arbitrary components, but for displaying non-visual controls. For arbitrary components, I think we should have a declarative syntax for them, and they should be persisted into the head, not in code (another v-next thought... in the same post).

While we're on the subject, check out the new System.Web.UI.NonVisualControlAttribute. Both the toggling behavior and intellisense listing tags for non-visual controls in the head section is based on that piece of metadata. Hopefully, it will be used to do more in the future, so start using it now, where it makes sense.