I, RESTicle
One of the last things I did at my last job was put together a web app called "Schema Explorer" that let you explore a SQL Server database. It showed a list of all tables and sprocs, and for each table you could view all the FK links, the names of any sprocs that called that table, and 20 rows of data. For a sproc, you saw the source code and (if your sysdepends info was up to date) you could also see the tables referenced by that sproc.
So yesterday I decided to recreate the Schema Explorer in the 2005 versions of SQL Server and Visual Studio. In the process, I remembered how much I really really really hate wiring up data to UI controls. No, really. So I ended up going back to my RESTicle design, and creating some base classes that implement basic HTML rendering, including parent/child navigation. There's still a huge amount of work to make a nice framework out of this, but I think I've proved to myself that this is the right way to go. At least for someone like me, who views UI design as nothing more than a necessary evil that should automated away.
For Harry's benefit, there's a barely functional snapshot of the schema explorer here. Unzip it in to your Visual Studio 2005 folder, and run the SchemaExplorer project. It currently uses a hardcoded connection string that assumes your running SQL Server on local host.
I've done this in C#, some of the annoyances there are:
1) I haven't yet found a nice way to get the object's URI and URL the same. i.e. I need to have the web server see an URL that points to an aspx. So for the moment the app uses URLs for the form http://example.com/Default.aspx?URI=/Path/To/Object rather than http://example.com/Path/To/Object
2) .Net doesn't allow for multiple inheritence. So I wanted a container class (RESTicleList) that was a RESTicle that contained other RESTicles. Since I wanted RESTicleList to subclass the generic List, I couldn't have it inherit the RESTicle functionality as well. Instead I needed to define an interface IRESTicle, and copy the same code into both RESTicle.cs and RESTicleList.cs
Anyway, not sure whether to continue to work on the C# RESTicle library (i.e. add XML and CRUD) or migrate to ruby. Speaking of which, reading this post by Peter Williams helped me clarify why I had that vague sense of unease about Rail's URL scheme.
Comments
I would say come on over to the Rails side. It is not perfect but you can write RESTful app in Rails. And there is a community of Rails users that are deeply commited to improving the RESTful behavior of Rails. I expect it will only take us a couple more months to work out how best to solve this problem in Rails (I know of at least two people actively working on different approaches). Ruby is such a nice flexible language that once we do figure it out what to do implementing it will be pretty straight forward.
Posted by: Peter Williams | February 8, 2006 02:39 PM
Actually, I think I'm going to build one to throw away. i.e., dabble with my c# code to work out what the issues with this approach are, then I'll be better placed to make good use of somebody elses framework.
Posted by: Jonno | February 8, 2006 03:56 PM
I think you could definately make http://example.com/Path/To/Object map to http://example.com/Default.aspx?URI=/Path/To/Object using IIS Rewrite. It's possibly not your ideal solution, given that you'd have to mangle your URLs in your app, and possibly change them for dev vs production. I'm also not sure what effect this would have on things like post-backs, but then maybe you wouldn't be using them so much in this style app.
Posted by: Harry | February 9, 2006 09:48 AM