etc…

(Note the [@commentable, @comment])

‘comment_form’, :locals => { :commentable => @user} %>

You don’t need to deal with @klass, constantize, etc.

And, in the comments controller, do something like this:

def create
@comment = Comment.new(params[:comment])
@commentable = @comment.commentable
@comment.save
…
end

one thought though, wouldn’t something like this be cleaner?

in the view:

render :partial => ‘comments_form’ bject => @object_to_be_commented_on

and then call comments_form.class.to_s to generate the string constant from inside the comments_form partial?

-h

polymorphic_url(@my_polymorphic_object)

it will redirect to the correct model, provided you have mapped its resources in routes.rb of course.

class Model < ActiveRecord::Base

but if I’m understanding all of this right, I think you meant

class Comment < ActiveRecord::Base

Also, in the first snippet under “Polymorphic Controllers”, you’re setting @klass as an instance variable in one line and then using it as just “klass” in the next line.

Just a couple of things I thought you might want to change for the sake of clarity to your readers. But thanks for the article; it was very useful to me.

Also, I know it’s not a real-life expample, but I’d but send_notification_email as an after_update method on the Meeting model itself, or in a MeetingObserver. I don’t think it belongs on a controller because it doesn’t fundamentally depend on the request.

You’ll be running into some greate problems if you have multiple common functionalities, which has to be shared between controllers.
For example if you have “comment”-functionality AND “rating”-functionality and you wannt to use sometimes both in the same controller.

I quess a better solution is to put the shared code into a module. In this way you’ll get the same dry-up and avoid the side effects of inheritance.

“live_user” as commenter_type would otherwise result in something like “Live_user” with capitalize/constantize. In case of clasify/constantize it will become “LiveUser”.