MissingHandle's Profile

I can't believe no one has taken to calling you Dr. Bates yet. Not just for your coding examples, but also because of your ESP in delivering these episodes exactly when others are in need of them. Thanks again!

@Bill Christian - to add to @moabite's comments, I think the controller is supposed to interact and know about models. Certainly, the view shouldn't make model calls, but the controller has to - it's the middle man between the two, no? Or maybe I miss your point?

I think you keep model/controller responsibilities separated by keeping the controller focused on scoping models and referring to as few model attributes as possible.

@Stephen Caudill, thank you! that makes so much sense. We've been doing too much specific assertion where if we change the name of an id of say, a link, things break.

Also, your blog post made me think that this application of the Single Responsibility Principle makes a lot of sense to integrate into cucumber step definitions down to maybe the link/id/css class level? Instead of calling a link or id directly, you call a method that returns the link/id. That way if you change a link or id, there's only one place to change it...that seems like it might cure the brittleness i'm hurting from and keep the features exact.

@stephen, how do you keep those integration tests from becoming brittle?

For declarative_authorization:

I just tried out the pattern (instead of the gem) to get a feel for it, as you showed in the first half. And I used the load_method option on filter_access_to. It cleaned the controller up beautifully!

Also - if you want your controller specs to pass, I think you need to make those private methods before_filters on your controllers. But, not really understanding action caching, would the before filters negate the benefit of it?

I wonder how seamlessly you could get this to work with declarative_authorization...

and +1 to @Nate Bird's question.