2005:
2006:
Turns out there's an awesome solution. I skipped this presentation at RailsConf, due to general hype fatigue - I needed a rest from REST - but it turns out I missed something awesome. Check the slides PDF for a way to get all the benefits of REST without any of the ugly repetition.
Ooh, that knocks the stuffing out of acts_as_resource, with the added advantage that I don't have to maintain it.
ReplyDeleteI wonder how well it plays with my latest (not quite released yet) toy; datestamped_resources, which builds you a resource of the form /resources/:year/:month/:day/:id and fixes up the named route helpers to allow to_param to return an array...
sounds handy for blogs!
ReplyDeleteExactly. I have the feeling that it's going to be, ah, interesting to fit it into Typo, which is what I developed it for, but it's reasonably non application specific.
ReplyDeletePersonally, I like the simplicity and flexibility of just inheriting from a pseudo-abstract Rest controller.
ReplyDeleteTim-
ReplyDeleteOur very, very earliest solution was to inherit an abstract controller. But, in the long run, we felt that it was easier to keep things clearly wrapped up in the Controller itself and utilizing a DSL for defining the overrides.
The implementation you linked to actually looks pretty good. It would make it easy to override any number of those helpers. Which, is exactly the tactic we took with ours. However, we sort of break ours up into more atomic parts. For instance... what if I like everything that "show" is doing, but I want the response to be different? I have to start from scratch?
Obviously, major changes require re-writing the entire action, but most of the time, we have found there is only one line or so I'd like to add or override about a controller action.
Anyhow, good work on that project (if its yours) and may the best implementation win! ;)
-hampton.
Really the only way to find out is to test them in the field. That being said, it's not necessarily a duel; probably the reason this stuff hasn't been wrapped up into Rails core yet is because it can be more effective when there are multiple solutions, since there are likely to be multiple problems for those solutions to address. REST is sufficiently complex that a one-size-fits-all solution would probably suck, so rather than the best solution winning, we may just see many solutions prosper.
ReplyDelete