Thursday, March 17, 2005

Scuppered by the parser...

I had an idea yesterday. I was going to write a simple databound ASP control.

The plan was to have a generic bound control, with a database connection, table name, field name and control type specified. The control, on databinding, would create a new database connection, read the values in and put them into the control of your choice (to start with it was just a choice of DropDownList or ListBox).

My thinking behind it was to make something very quick and dirty to drop onto a page, but keep the page design fairly clean. Assuming there was already a database connection being used somewhere on the page already (as there is bound to be), it would look something like this:

<MyControls:BoundControl runat="server" ID="BoundControl1" Connection="NorthwindConnection" Table="Categories" Field="CategoryName" />

Neat, I thought. It's slightly easier to use that a normal ASP:DropDownList, and still fairly efficient since it makes use of the existing connection that the page has created.

Put it together, and it compiles nicely. Drop it on a page and it looks fine. Feed it the properties it needs. Visual Studio even gives you a nice dropdown in the properties grid of all the database connections already on the page in the designer. All hunky dory, I thought.

Hit F5, compiles nicely (as I would expect, this is my code after all (fnar fnar!!))

But no. I'm just about to sit smugly back and have a post codal cigarette, when:

Unable to generate code for a value of type 'System.Data.SqlClient.SqlConnection'. This error occurred while trying to generate the property value for Connection.

It turns out that the parser can't give that property to that object. If, however, you set that property at runtime, then you're fine.

Ideally I was looking to have everything do-able in the designer (designtime support was the next thing on my list of things to look at) but if I can't set the connection at design time, then it doesn't work so good. You end up with some properties being set-able in the designer, and some only available in the codebehind, and I can't say I'm too much of a fan of doing that.

Failing that, I'm left with 2 options:

  1. Make the connection string a property of the control, and have the control itself create a database connection (not ideal - imagine if you had a form with 15 fields, and each of those fields was trying to create and open a new database connection)

  2. Pass some other sort of data-object into the control. A Dataset for instance.
As you can see, neither of those choices really works. One sucks up unnecessary resources, while the other one doesn't save me any work at all. If I'm going to be creating page-level datasets and stuff like that, then I might as well just use the built-in ListBox and DropDownList controls.

And all because the page parser was "Unable to generate code for a value of type 'System.Data.SqlClient.SqlConnection'".

I'm going to have to find something else to do with the next couple of evenings, now.

Maybe I'll speak to some real people. I've been told that's what normal people do...

Apologies for pointless rambling.

No comments: