(2006-07-01) Dhh World Of Crud
DHH asks What if the whole world could be modeled under the constraints of CRUD?... There's a rejuvenation awaiting you. One that'll simplify your controllers, bless your application with an almost-free ReST API, and elevate your domain model even further away from the depths of anemic. (Video of his Rails Conf talk on this topic available.)
-
how well do the CRUD functions map to HttpPut, HttpGet, HttpPost, and HttpDelete? (note that most Web Browser-s support only 2 of those 4 HTTP actions)
-
- A lot of Thirty7 Signals controllers have way too many actions (MVC) - I think he said the worst had fourteen. This is a bad code smell - too much complexity in one class, not enough separation of concerns.
-
Jan'2007 update: Ruby On Rails v1.2 is out, with even greater support for this vision.
-
We're taking Mime Type-s, HTTP status codes, and multiple representations of the same resource serious. And of course there's the international pizzazz of multibyte-safe UTF-8 wrangling.
-
You too can transform that 15-action controller into 2-3 new controllers each embracing a single resource with CRUD-ing love... The only real API element that binds all this together is the new map.resources, which is used instead of map.connect to wire a resource-based controller for HTTP verb love. Then, once you have a resource-loving controller, you can link with our verb-emulation link.
-
While respond_to has been with us since Rails 1.1, we've added a small tweak in 1.2 that ends up making a big difference for immediate usefulness of the feature. That is the magic of ":format". This makes a shoulda-been-obvious point to me: while you typically keep much of the auto-generated CRUD interfaces from a framework like this, auto-generated non-HTML representations (e.g. XML) are much more likely to be fine without retouching.
-
Edited: | Tweet this! | Search Twitter for discussion