Advanced resource_controller usecase

[Sean Schofield]

First off, nice work on this plugin. Up until now I have been
skeptical of REST since it didn't seem to offer much except more
hassle (ie. stubbing out a bunch of controller methods.) This
approach finally represents a long awaited payoff to using REST.

My question is about how to use resource_controller in a complicated
webapp with role restrictions and a few other subtleties.

Project
has_many :requests

Request
belongs_to :project
has_many :options
has_many :comments, :as => commentable

Option
belongs_to :request
has_many :comments, :as => commentable

Comment
belongs to :commentable, :polymorphic => true

The tricky part (for me at least) is developing views that go beyond
the simplified list of all objects and another containing an edit form
to update the object. For instance, I need an edit screen for
requests that will allow users to add new options, comments, etc. Is
there an elegant way to use AJAX to create/modify these resources? I
suppose I could bring up a new page to create an option but then you
lose the work you've done on your form thus far.

Also, the only access restriction use cases I could find are ones that
use namespace to separate functionality. I don't really want /
requests and /admin/requests. I just want /requests to show an admin
view that's smart enough to show the right views, etc. I have a
solution for roles (the role_requirement plugin), I just need some
help tying it all together.

I realize that some of this is a little beyond the scope of
resource_controller but I could really use some help with using
resources beyond trivial cases. If someone has some code they could
share with me (either publicly or privately) that would be great.
Otherwise I will settle for some good advice based on your
experience.

[James Golick]

As far as showing other models' forms and things in the scope of a parent resource, there's nothing wrong with just render()'ing the form right there, and using ajax, or regular requests to submit it. I tend to be sparing with my use of ajax, and just render child model forms in-line. To edit child models inline, and submit them all to the same place, check out my attribute_fu plugin http://jamesgolick.com/attribute_fu

As for rendering differently based on role:

edit.wants.html do
  render :action => current_user.admin? ? 'admin_edit' : 'edit'
end

...or if you have a lot of different roles, something like this might work pretty nicely:

edit.wants.html do
  render :action => "#{current_user.role}_edit"
end

In case you're not aware, render :action just defers to a template by that name in the current controller's view path. You don't actually need an action by that name in your controller.

Hope that helps

James

[Jason Boxman]

I've been using as suggested:

index.wants.html do
render :action => "#{parent_type.to_s.underscore}/index"
end

It's not perfect, since the template is under polymorphic_controller/
parent_controller instead of parent_controller/polymorphic_controller
which I'd prefer. It does allow custom templates for polymorphic
controllers, though.

The alternative is logic in the view template itself, which I'd like
to avoid for this sort of thing.

So, it ends up being

comment/request/index.html.erb
comment/option/index.html.erb
comment/_index.html.erb
request/_menu.html.erb

For the common stuff, I include a partial and another with menu
options.

render :partial => 'comment/index'
render :partial => 'request/menu'

And that can easily be a helper that uses parent_type to determine the
right template path for the sub-menu header I have.

r_c makes it pretty easy. I am essentially pleased with the result.

I was messing with namespaces and stuff to try to achieve nesting a
non-polymorphic controller with no view switch logic at all as say,
Request::Comment, but it was far more pain than it seemed to be worth.

(I discovered that CommentController and Request::CommentController
may collide or some such, but I am uncertain the resolution.)

http://www.ruby-forum.com/topic/125392

Instead, if Request needs another instance variable for, say, the
index action, while Project does not, I ended up with

index.before do
case parent_type
when Request then
@request = parent_object
end
end

which I'd need to do anyway with a r_c controller that wasn't
polymorphic.

Thanks!

> usenamespaceto separate functionality.  I don't really want /