Ok guys, its been a while since I've posted here. I don't think I've
had a Rails feature added since the hash-as-conditions patch from
forever and a half ago. I've been busy building apps and working on
new languages. Oh, well and working on make_resourceful too. I'm not
sure how familiar you guys are with make_resourceful but its a tank of
an abstraction that helps "ninjas" to build really abstracted code for
their resource based controllers.
Ever since the beginning, I knew that m_r wasn't right for Rails core.
It was best as a plugin. There was a ton of magic and mystery in it...
and frankly. It did too much. Lots of people use it today and enjoy
it, but it requires *learning* a lot of new stuff to use it
I've been getting a lot of emails recently asking "what's next" for
m_r... and so it got me thinking. What _is_ next? m_r has solved my
issues with app development for 90% of my controllers for the past
year and a half. So, should I really add anything?
Then, it hit me. Why not take the lessons I've learned from being a
professional rails developer who has done (GASP) 14 production Rails
apps with resources and come up with something a lot less ninja, and a
lot more core.
So, here is the idea. One of the best things that m_r does is give you
nice accessor methods for the resources you are currently working
with. I noticed that in most of my controllers I was repeating lines
like this..... "User.find(params[:user_id]).messages.find(:all)".
Over, and over, and over, and over again. Even with the create method
for that "message", I'd want to scope it,because I'd want the magic of
having an automatically assigned user_id on the message (or, I'd just
be lazy and do a second line). Anyhow, that's the least DRY part about
doing a resourceful controller. Accessing the stuff you want.... over
and over and over.
So, here is my proposal: http://pastie.org/230474
The way its structured is first is a really simple example. Followed
by two complex examples, THEN followed by those last two examples in
their *explicit* form. Basically, the explicit form is the code that
would be automatically added by the ::load call.
Basically, you call the class method "load" on ActionController::Base
and pass it an array of classes or symbols (read the code there to
figure out the symbol bit... I'll just stick to classes here). The
last arguement to it is your resource. And the ones before it are the
If I say "load User"... it builds four methods.... #user, #users,
#build_user, and #update_user. Read the explicit versions before to
get the gist of what each one of them does.
The problem with m_r and other proposals are that they assume too
much. However, I think that this is just the right mix. I'd be
surprised to find a resource controller that couldn't be cleaned up by
Too much magic? Not really. Think of it like belongs_to for your
controllers. No one complains that belongs_to "creates" (I know, not
literally) methods on your AR models.
I'd love feedback on this. If its not right for core, I'll just make a
plugin and go about pimping it. If it seems like something that MIGHT
be interesting for core, then I'll fork and fiddle.