Dynamic Data Controls Need Work

One of the minor announcements at MIX '07 was Dynamic Data Controls, part of the ASP.NET Futures release. It's like Rails for ASP.NET, which is very welcome. I recommend checking out the video if you aren't familiar with Rails. Essentially, it turns the URL into the command, so http://www.example.com/Tasks/List.aspx shows a list of tasks.

If you're looking to make something like this now, take a look at SubSonic. The new version create classes that work very well with the DataSource objects.

Brian Dougherty makes a point that it's not practical because there's no enterprise-level features like security. I'll guess that a lot of those concerns will be addressed by the time Dynamic Data Controls releases by using something that already exists in the ASP.NET world in some way. Rails seems to be the model and it doesn't have a lot of these enterprise level features either.

The video shows how easy it is to make an ugly GridView / DetailsView / FormView page for a table in the database. I don't think it's practical because it's way too ugly. Even the ability to create the control and attach the Dynamic Data Control as an extender is too limiting. Does anyone else agree that the data controls aren't suitable for a site made for a client? They require so much work, it often seems easier to use a stupid Repeater.

The Value of this.

I've noticed a lot of sample code that uses "this." before using members of the current class. I generally don't; I sometimes type "this." to get Intellisense help but take it out for consistency. Is there a technical reason to put it in there?

End of ASP.NET?

I just watched Scott Guthrie's Silverlight 1.1 screencast. It's very promising. It looks like they have everything to make the technology work and now they need to get everybody to take it seriously. I don't think they'll have a hard time with developers; it was a big hit at MIX '07. The harder part will be convincing people to install the plug-in or designers to learn Expression Blend.

Assuming it gains critical mass, will anyone continue to make regular ASP.NET HTML-based pages? Silverlight-based pages look better and are easier to develop. Javascript is a fun language but it's dynamically typed, embedded in the page instead of on the server and can't leverage existing .NET libraries. Not having to deal with cross-browser HTML quirks may be worth it.

I'm hoping Silverlight catches on.

Snippets

Both Visual Studio and Dreamweaver come with tons of snippets. (C# versions of the VB snippets that are included with Visual Studio can be found here.) The snippets look very useful but I'm just not used to using them, so I don't. I'm trying to make an effort to look through the snippets before typing, but I rarely remember. How does anyone else add something like this to their repetoire?

Free Development Tools and the Command Line

My last company spent a lot of money on development tools. Every developer has an MSDN subscription with a Team System license. (They wouldn't buy me Resharper or another GB of RAM, but that's another story.) Since I've moved companies and now I have no budget, I've had to use cheaper tools.

Subversion and Trac have both done a great job. I spent a while looking for a way to integrate Subversion into Visual Studio and couldn't find a good way. It turns out that TortoiseSVN is just as good as VS integration. TortoiseSVN is integrated into Explorer and it makes your folder into the working copy of the repository. Right click and click on "TortoiseSVN Commit..." and all of your files are updated. Trac has really helped me get organized which is really necessary when there aren't any other developers.

I also finding myself using the command line more often. Subversion without TortoiseSVN is based on the command line. Trac projects are initialized and administered by the command line (although administration can be done via the web interface in the next version or with a plugin). I've almost become afraid of the command line as I got better with Visual Studio and had tools with GUIs, but it's pretty useful. I wish PowerShell didn't have such a steep learning curve, I may be better off writing simple one-off console-based applications.

What actually takes the most time?

Next time I write a web page, I'm going to try to keep track of how much time I spend on each task. It seems like I spend the most time doing repetitive things. These are the types that are most easily done by the computer. Two things quickly come to mind. The first is creating a row in a table that has a label and a form field and the second is collecting the form input and putting it into a data structure.

The first could be solved by a user control. I haven't created one yet because it's not trivial. It needs to be able to handle every option on every form control and it needs to be flexible enough that my designer won't nitpick that it doesn't look exactly like the screenshot. This makes me think about whether it's worth the time investment because creating the row is really quick. I've forgotten about the secondary gain: having a form-independent way to create a form.

The Pragmatic Programmer makes the point that it's better to work closer to the domain. This means using their jargon and letting the domain experts define the requirements. It would be very quick and productive if they could type up something that the web site will parse directly into a form, even it's just a prototype.

The second thing isn't just to save time. A class that takes the form response and fills in properties on a data class would be very useful. I haven't done this so far because of the myriad validation possibilities and it requires reflection (which makes me pause but it shouldn't). There are many possible ways to handle validation, including the Validation Application Block or to handle it completely separately.

Web Site Frameworks

My current project has me working in Coldfusion, which is very different from ASP.NET. The most fundamental difference is that it doesn't try to use controls and objects in a codebehind. Coldfusion makes it easy to run queries and output results but mixes database code in with HTML. On one hand, pages are in one file and database access is very easy. On the other hand, the form is strongly typed and you can easily modify page elements in code but the viewstate is quirky but too useful to turn off. They're quite different and I don't know which I like better.

Given only those two choices, I'd go with ASP.NET. Subsonic takes away a lot of the pain of the database access and it's just really handy to be able to say "DropDownList1.Items[1].Selected = true". I think the Coldfusion / ASP method may have more potential with an awesome IDE that's realizes that it's creating a web app (make it easy to get to the querystring / session / database). A hybrid method may be good, something like using HTML controls with properties but that don't get persisted across postbacks.

Rails has a completely different paradigm where you don't create pages, you create controllers and views. I think the best thing about this is that all of the code concerning an object is in one place. Each page has its own view that has very little code. The distinction seems to get murky if you want AJAX because you need javascript code in the view. Also, the view and controller are loosely connected with only an implied contract and unit tests, so I don't know if this is the best way to go either. It probably has the most potential with an awesome IDE, but it doesn't have corporate backing which means that IDE isn't coming anytime soon.