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.

Javascript as a Learning Language

A popular question is what language to start with when teaching a novice how to program. I've seen C and C++ dismissed as too complex and I agree. Java / C# are usually passed over because of all of the explanations necessary for Hello World. I agree with this too because you'd have to tell the student to ignore import, static, void, arrays, braces and explain what the Console is. Usually the next things considered are Perl, Python, Ruby and Bash. I'd go with Javascript.

First, good tools are very easy to obtain. The novice is probably using Windows and would need to download the script interpreter. All you need for HTML and Javascript is a text editor that colorizes such as Crimson Editor or Programmer's Notepad. Running the test involves double-clicking on the HTML icon on the desktop which is not intimidating at all.

Teaching JavaScript allows you to start with HTML, which is very easy to learn. It's easier to understand markup because it's easy to look at the HTML and see "The quick brown and then fox is surrounded by strong and then jumps over the lazy and then dog is surrounded by em which means emphasis." You get to make something cool very quickly when the teacher goes into colors, backgrounds and images.

This leads well into JavaScript. There's an instant UI using the alert, confirm and prompt functions. There's very little syntax that needs to be explained to get started and nothing needs to be skipped. "The tag is called script because we're going to use JavaScript. We're going to alert the user by telling them a number. Type alert(16)."

One day I'd like to put together a "Programming from Scratch" series of screencasts, but I doubt that I'll be able to do it soon.

MVP and Unit Testing in ASP.NET

His picture notwithstanding, it's pretty clear that J.P. Boodhoo is an intelligent guy. I watched one of his screencasts about MVP in ASP.NET and unit testing and I'm a little puzzled. He creates four class library projects to support this paradigm: one for the models, one for the presentations, one for tasks and and another for the DTOs. Even with Resharper, that seems like a lot of work to create a web form with four fields. I'm interested in hearing the arguments for unit testing something as simple as this.

Test Plan as Requirements

My first project at my new job was a pretty simple web site. I didn't use the data controls (like DetailsView), although they would have been appropriate. I didn't write unit tests either, mostly because the application fills out forms that directly reflect auto-generated SubSonic classes. There was one place where I should have written unit tests, but only one. I did write a test plan.

A test plan, in theory, should cover every behavior that the application should exhibit. If the application is supposed to flash the background color every 10 seconds, there should be an item on the test plan that says "The background color flashes every 10 seconds". If there's no requirement for that to happen, it shouldn't be in the test plan. So the test plan should echo the requirements document, if you have one. Which you probably don't, so writing a test plan gives you requirements.

The real reason to write a test plan is to separate you the developer from you the tester. Testing something that you developed is tricky, because if you just dive in and test, you're not going to test very well. You're going to test the things that come to your mind, which is probably the things you worked on the most, which probably doesn't have bugs since you worked on them the most. Writing the test plan properly, by looking at the UI and writing down everything it should do, separates these two personas.

Web Services with Prototype and ASP.NET Ajax

Here's a link to the handler: http://www.subtlereality.com/wsproxy.ashx.html

As I've mentioned before, I don't like using ASP.NET Ajax's client code. I like using web services because they're easy to develop, but I can't find a good SOAP library for Javascript. This makes calling web services difficult. After waiting for a while for someone to write one, I decided to take my own shot at it. My project already uses Prototype, so I decided to use those AJAX tools. It was a lot easier than I thought.

My approach was to figure out how ASP.NET Ajax called the web services and use that method. It clearly knows how to do it. I rolled up my sleeves and delved into the JavaScript library and found.. no SOAP envelope in the entire thing. I dug deeper and found that it sends POSTs with a content-type of "application/json" and the body is a JSON-serialized object. That was easy enough.

The trickiest part was the date serialization. Nikhil Kothari explains the issue in this blog post. Microsoft used "@1234@" in the Atlas betas but switched it to "\\/Date(1234)\\/" which is a lot more frustrating because you need to count slashes and try to figure out how often your string is being interpreted.

In the end, I came up with a HttpHandler that mimics the ".asmx/js" files that ASP.NET Ajax uses. You need to pass in the path to the web service and the .NET class name as arguments through the querystring. For example:


It doesn't deserialize DateTimes as the return value and you don't have as much control over it. If other people start using this, I'll start a real website for it. Feel free to ask me any questions about it.

SqlDataSource

I used the SqlDataSource for the first time today. I switched jobs and now I'm the only developer in the company. It's something I would hate to do if I thought someone else would see it or anyone (myself included) would have to maintain it. I needed to grab html out of the database and spit it onto the page and I did the quickest way I could think of: a SqlDataSource and a Repeater. The Repeater is pretty bad too because there will never be more than one record, but it was quick and it worked. Is the "proper" alternative to load the data in the code behind and stuff it into a literal? Too much work and no gain.

I've posted about unit tests and patterns recently because I thought that I'd need to be more vigilant because I'm the only developer. That may be so for more complex tasks, but spitting out the result of "SELECT html FROM dhtml WHERE id = 4" isn't complex enough to warrant that. I'll need to revisit it when I implement the page that lets you edit the html and I'll rewrite it then if necessary. By then, I'll have SubSonic ready to go.

I'll take the quickest and easiest path, as long as it's reliable.

UPDATE: I took them out today. I had two different kinds of SqlDataSources. One was easier to replace with one line in the code behind. I'm always in favor of less code. The other needed to be rewritten and it required more logic. It was in 4 places so I replaced it with a controller.

Great Intro to Refactoring

This PDF by Thycotic Software is a great explanation of refactoring and unit testing in C#. They took a chapter of Martin Fowler's book Refactoring: Improving the Design of Existing Code, translated the code into C# and added some unit tests.

Video on ASP.NET Databinding

http://blogs.interfacett.com/dan-wahlins-blog/2007/3/25/video-binding-data-to-aspnet-20-server-controls.html

This video from Dan Wahlin is a really good tutorial of a master-detail view. The trick is to use "DetailsView1$dd" as the ControlID in the ControlParameter when updating or inserting. It's not very intuitive and it looks like a hack but it seems to work. I've mentioned my troubles with code-free databinding; hopefully this will set me straight.

ASP.NET vs. Ruby on Rails

If you're a contracter and you're being paid a flat fee to develop a simple website that basically only collects data and creates reports, what language and toolset do you use? You don't have to every do maintenance and you can't fix bugs. You want to get it done as quick as possible since you're being paid a flat fee. You have the freedom to choose whatever hardware and software you need. Obviously, your personal skill set is important in determining your answer but for me, it's a decision between ASP.NET and Ruby on Rails.

I believe in RoR. I think that it's a great way to build a website, especially one with requirements like these. My main issues involve its maturity, its tools and my familiarity with Ruby. Maturity isn't a problem in itself, but there are other problems that will go away with time, and I see this as an immaturity issue.

There's too much room for error in deployment because I have to TTY into the server and type things into a command line. I also feel like I need to know a lot more about Apache or FastCGI or Mongrel or whatever. I don't trust the RoR tools. There don't seem to be very good IDEs for working in Ruby, largely because Ruby is so dynamic that a new type of tool is required. The libraries are untrustworthy because they're not standard. I don't want to deploy (or even work with) a library with bugs, and I don't know where to find out which is the mature library.

I'm only considering ASP.NET a viable option because of SubSonic. Without that library, I'd spent way too much time writing and debugging data access code. The issues I have with ASP.NET are the inability to create unit tests without bucking the framework and unnecessary complexity of using controls instead of HTML. ASP.NET doesn't do MVC. It has views and no controller, which is quite untestable. Last I used it, NUnitASP was the best way to test it but it couldn't come close to testing an entire site with AJAX and everything else. I've become increasingly uncomfortable with using the ASP.NET controls when they're anything more than thin wrappers around HTML controls. (Except the Login controls in 2.0 which I love. Feel free to stop reading now.) As I rely on them more, I see more side effects and I find that I'm fighting with them or writing code that I feel is like a hack. A master-detail view should be easier and have fewer corner cases.

MonoRail is getting close to usable but it doesn't have a view engine I'm comfortable with. I fully acknowledge that it may be the best option, but I'm going to need to test it out first, and I haven't.

I'd go with ASP.NET. I think it may take slightly longer but it would be easier. The tipping point is RoR's toolset. With ASP.NET, I can use Visual Studio and set up pages using the designer.

Smart Clients and Web Clients

I don't think there's an accepted strategy on the smart client / web client decision. Smart clients are desktop applications that get their data from the internet and have a reputation of being more powerful and easier to use while web clients don't need to be installed and are easier to update. With AJAX, great design and clever Javascript, the web can provide as much functionality as a smart client. Similarly, web services can let smart clients use the same real-time data as well as clients. So which is better?

Let's not ignore the possibility of both. Would it be good if we had a choice? We could use the smart client at our main computer and the web client on the road. Well, if we have a web client, why do we need a smart client? Is the UI so complex that there's a significant advantage to a smart client?If so, maybe the solution is to make the UI simpler. Also, would they work the same? There are toolkits like Visual WebGui or GWT that may let us use the same UI for both clients, but if the smart client isn't significantly better, we may as well not create it. They also don't work very well; the web and desktop aren't the same and aren't easily abstracted away. Throw in the extra work for creating two clients, regardless of whether they use the same UI toolkit, and this is a no-go.

Except for one situation, I'll go with the web client, especially in the long term. Web UIs are simpler and allow for more branding. They're easier to get working for different operating systems and it's the platform that is improving faster. There's Flash if you need a complex UI. The main problem that I see is that good UIs are difficult to create. AJAX is necessary but it isn't an easy concept for developers to grasp. This is slowly being alleviated through new libraries such as Prototype, ASP.NET Ajax and Flex; I believe it's worth putting the effort into the web client and it will be easier to benefit in the near future.

The situation that I'd go with a desktop client is if there's a compelling technology that's not available on the web. 3D is a good example of why games on the web are generally puzzle games or simple action games. WPF is possibly the only technology that makes a smart client desirable, and that's not insignificant because it's a very nice library. I'd say that audio (music) is another thing the desktop does a lot better than the web, but sites like Slacker and Pandora have web-based music players that are pretty good.

In short, I'd go with the web client unless it's prohibitively expensive.

Google Maps and Web Controls

Google Maps is probably the most revolutionary piece of software released on the web in its era. Compare the old map interfaces with a small yellow map, ugly fonts and arrows on each side so you could pan by getting a whole new map. Google Maps uses the whole screen, has pretty fonts and doesn't redraw. It is a tremendous user experience on the web in a time when the web meant the UI was mostly forms. It kickstarted the notion that the web can be as pretty as a desktop client.

At the moment, it still takes a ton of work to get a good user experience out of a web application. There are lots of browser compatibility issues, poor JavaScript editors and a lack of integration with server code to deal with. Libraries such as Prototype and jQuery are beginning to solve some of the issues but these are really just the base of an overall solution. EXT is probably similar to the next generation of web libraries: a layer on top. YUI has both a layer on top of JavaScript and controls using that layer.

Using controls with server code may also be the future. We already have tons of code the runs on the server, as well as the necessary ability to access the database. ASP.NET Ajax is Microsoft's attempt at increasing the web experience and we'll have to see if that can serve as the basis for more projects than the Control Toolkit.

Script# is a very clever attempt at writing JavaScript code with C#. You could even write Vista Sidebar Gadgets with this library. This seems to be a promising avenue but the developer (a Microsoft employee) seems to have stopped development. GWT is a more mature effort to write JavaScript with Java, but I have no experience with it.

The situation will shake out over the next 5 years or so. By 2012, creating a web application with a great UI should be standard. We should have enough research into UI design by then, too. Hopefully the browser manufacturers will cooperate by standardizing their JavaScript and layout engines, but it doesn't seem to be necessary.

Betas and GAX/GAT

I used to love installing betas and trying out new ways to code. I still enjoy it, but all that time taught me that the same thing will happen after a certain amount of time. The WOW part of the beta will be wonderful and exactly as explained. Continuing to build will inevitably lead to the point where you cannot accomplish what you want. The docs say it will do one thing but the forums confirm that what you need to do is broken and can't be done. Of course, if everything was working they wouldn't be betas, they'd be products.

This mentality has prevented me from installing GAX and GAT. They are Visual Studio 2005 extensions that come with recipes that make it easier to create and use frameworks and thus easier to write code. This is the kind of thing I love, and I made the mistake of downloading and installing it. No joke, and maybe it was a coincidence, but my shift key wouldn't work in VS 2005 until I uninstalled. I wasn't expecting too much and I'm still interested in the technology, but I decided to wait until the final release before trying it again.

The first beta was released in May 2005 and now it's March 2007 and I can't find any release date. This is discouraging. The Smart Client Guidance seems like it would be useful, but I need my shift key.

ASP.Net Ajax as a Tool

Libraries are abstractions that make it easier to do things that can already be done. Sure, you could write your own code that parses XML files, but it's a lot easier, quicker and more reliable if you use one that someone else wrote. If that library doesn't work correctly or doesn't make the job easier, it's not usable. Flexibility is a bonus. It's useful if you can use the same library for image resizing and image format conversion but if there isn't one, you can just use two libraries. If a library is too inflexible, it becomes usable. A library that takes any image and resizes it to 32 x 32 isn't useful at all if I want 48 x 48.

ASP.Net Ajax is an odd case. It makes some thing extremely easy, and for that alone it's going to get wide usage. UpdatePanels are an extremely easy way to avoid whole page refreshes for minor changes and lower bandwidth usage. The Control Toolkit has a little bit of a learning curve but it's also a great tool to do some useful things on web pages.

It's almost a shame that the javascript libraries are a mess. They are extremely intimidating, and my attempts to dig into it have been discouraging. Javascript is a very lean and powerful language and I have to wonder if there's a benefit of a namespace and class system is necessary. The UpdatePanel and Control Toolkit is built on top of the javascript libraries, so I'm going to have them at my disposal and I may as well use them.

I want to use them. There are problems I'd like to solve that require Javascript and I don't want to bloat my site with more than one library. Specifically, I'd like to go to the server, do some processing, and send back code that modifies one element on the page, similar to Unobtrusive Javascript in Rails. The UpdatePanel is overkill, it will update the entire section. I don't think ASP.Net Ajax can do this explicitly and I would like to write and share an Unobtrusive Javascript control for that library, but I don't know if I will. It seems like it will be much easier to avoid using the javascript library and create a separate library that I would probably not share.

OR/M and SubSonic

OR/M is the easiest way to get data out of the database without writing the code necessary to access the database. You can just use objects with methods like Load and Save. The technology is just beginning to leave its infancy stage and many libraries are difficult to configure and use. NHibernate was the first OR/M that I got working and it provides a tremendous productivity increase. However, you still have to use a code generator to create your objects to start and every time you update your DB. NHibnernate's delays in updating to a codebase where you can use generics and nullables had me looking for a new OR/M. Elementary looks interesting but you still have to generate and regenerate the class files.

SubSonic doesn't have that problem. It's written by the guy who does the Commerce Starter Kit, which I've never looked at but it seems like a good project. It's currently designed for web sites projects and uses a build provider to generate the classes. It also generates classes for views and stored procedures, which other OR/Ms don't concern with because of idealogical problems. The next release will include a custom build tool that will extend this feature to libraries and Windows Forms projects. It's also very easy to use and greatly cuts down on necessary code, even over HNibernate. Subsonic is still getting features but there's an active community.

Microsoft is working on an OR/M called LINQ that looks like it will become the de facto standard. Recent CTPs of Visual Studio Orcas have included it but I haven't used any of them. LINQ is going to have to be pretty good to beat SubSonic.