I saw a post just now about how Java is supposedly more productive than Ruby on Rails at building web apps. After I stopped chuckling, I read the post and noted that "easier" in this sense meant using a model driven approach with a framework that generates the HTML views for you based on your models. Hmm - been there, done that with VisualWave. It works great right up to the point where you want to start customizing things - at which point the code generation framework starts hurling walls in your way.

So what's behind door number three then? Well, there's Seaside with Web Velocity. First, let's define the database. First, I tell the system I'm using PostgreSQL and give it my login credentials. Then I give it these two methods:

tableForCATEGORIES: aTable

	(aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey.
	aTable createFieldNamed: 'name' type: (platform varchar: 200).

tableForRECIPES: aTable

	| category_id |
	(aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey.
	aTable createFieldNamed: 'title' type: (platform varchar: 200).
	aTable createFieldNamed: 'date' type: platform timestamp.
	aTable createFieldNamed: 'description' type: (platform varchar: 200).
	aTable createFieldNamed: 'instructions' type: platform text.
	category_id := aTable createFieldNamed: 'category_id' type: platform integer.
	aTable addForeignKeyFrom: category_id to: ((self tableNamed: 'CATEGORIES') fieldNamed: 'id').

At that point, I had a database (I did have to click the link for creating tables), basic viewers for the recipes and categories (and I used that basic app to add some categories and recipes). Here's a screenshot of the basic recipe viewer:

It's not showing us stuff exactly as we'd like, but it works - we can add recipes and categories. Here's what it looks like after a few customizations in the code, making the scaffolding framework display what we want it to:

And the viewer for an individual recipe:

Now, what did I have to do to get that? Simple. In my List viewer for recipes, I added a couple of methods:

shouldRenderInstructions
	^false

renderObjectCategory: object value: value on: html
	
	html anchor
		callback: [self call: (CategoryViewUI on: object category)];
		withOverflowSafeText: object category name

renderObjectDate: object value: value on: html
	html text: value asDate printString

The first tells the class not to render that named field (you can do that for any of them in specific viewers, and an equivalent thing can be done for editors). The next two tell the viewer how to render two specific fields - with the one for Category telling it to provide a link to the category viewer. I provided some niceties in the category list view as well:

shouldRenderRecipes
	^false

Which has it list just the category names, with links to each recipe. Then there's the modification to the viewer for a recipe, to have it display HTML instead of text for the instructions:

renderValueInstructions: value on: html
	html html: value

That has the Instructions field render as html instead of as text. That's pretty much it - There's a lot more that can be done, but the cool thing is this: it's all done with your models and views, with a nice clean separation between them, and complete control over how everything displays. If you don't care for the default scaffolding, you can override it completely (by implementing #renderContentOn: yourself), or just for the main content area, by overriding #renderDetailsOn: ). As I showed above, you can change things on a more fine grained basis easily as well. I'll take complete control via code over a naked object style approach any day. And oh by the way - while I used the ActiveRecord pattern which Velocity provides here, there's a full ORM - the open source Glorp framework - behind it.

Technorati Tags: java, ruby on rails, web, development, seaside