What is the right way to monkey patch rails?

Rails
1

I need to change a little method in rails, specifically the
authorization method in ActionController::HttpAuthentication::Basic
(which uses a fixed list of authentication env locations that doesn’t
include what my server does).

Right now the way i do it is i have at the end of my application.rb file

module ActionController::HttpAuthentication::Basic
def authorization
#code here…
end
end

Is there a better way of doing it?

2

Sam C. wrote:

Right now the way i do it is i have at the end of my application.rb file

module ActionController::HttpAuthentication::Basic
def authorization
#code here…
end
end

Is there a better way of doing it?

That looks like a standard Monkey Patch.

Got unit tests for it?

–
Phlip

3

Phlip wrote:

Sam C. wrote:

Right now the way i do it is i have at the end of my application.rb file

module ActionController::HttpAuthentication::Basic
def authorization
#code here…
end
end

Is there a better way of doing it?

That looks like a standard Monkey Patch.

Got unit tests for it?

–
Phlip

hehe… nope.

4

Sam C. wrote:

Is there a better way of doing it?
That looks like a standard Monkey Patch.

Got unit tests for it?

hehe… nope.

Ordinarily, the correct way to do anything - especially an MP - is to
unit test it.

However, in the case of Basic Authentication, you would need to mock the
server… and the authorizer… and so on. The mocks would generally
tell your
test what they think it wants to hear, and you’d be back to square one.

So maybe the question how to monkey-patch something is isomorphic to the
question how you reasonably test it.

Just make the monkey patch as small as possible, and then submit it to
the
maintainers… C-:

–
Phlip

5

Hi –

On Thu, 6 Mar 2008, Phlip wrote:

Ordinarily, the correct way to do anything - especially an MP - is to unit test it.

However, in the case of Basic Authentication, you would need to mock the
server… and the authorizer… and so on. The mocks would generally tell your
test what they think it wants to hear, and you’d be back to square one.

So maybe the question how to monkey-patch something is isomorphic to the
question how you reasonably test it.

It’s possible to write your model classes inside a view, and then test
them, but I still wouldn’t recommend it :slight_smile: I’m all for testing, but I
don’t think that discussing best practices in other terms has been
discredited. Also, there are tests for this class already, which could
probably be adapted (depending what the new version is doing, of
course).

David

–
Upcoming Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS, April 14-17 2008, New York City
CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!

6

David A. Black wrote:

It’s possible to write your model classes inside a view, and then test
them, but I still wouldn’t recommend it :slight_smile: I’m all for testing, but I
don’t think that discussing best practices in other terms has been
discredited. Also, there are tests for this class already, which could
probably be adapted (depending what the new version is doing, of
course).

You are answering the question “how can I use tests to help bad
designs live longer?”

That’s a valid question and answer, but it’s non-responsive to my
point.

The goal, if you must Monkey Patch, is to slightly increase the odds
of a clear diagnostic error message when the real library upgrades out
from under the patch.

–
Phlip
http://assert2.rubyforge.org/

7

Hi –

On Fri, 7 Mar 2008, Sam C. wrote:

#code here…
end
end

Is there a better way of doing it?

(Written under protest, because you’re making me respond to the
loathsome phrase “monkey patching” :slight_smile:

Off-hand it looks to me like that might be happier living in the
config/initializers directory, assuming you’re using 2.0 and that
putting it there would have the same effect. It feels a bit buried in
application.rb, whereas if it were in its own file in initializers, it
would be more on the surface of the code and easier to find and/or
notice.

David

–
Upcoming Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS, April 14-17 2008, New York City
CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!

8

Hi –

On Sat, 8 Mar 2008, Phlip wrote:

You are answering the question “how can I use tests to help bad
designs live longer?”

No, neither asking nor answering that question :slight_smile: I just mean that I
don’t think that “Can you write a ‘reasonable’ test suite for it?” is
the beginning and end of all examination of whether a given practice
is a good one. Among other things, test suites are constrained by test
tools, the current state of which I admire greatly but which are
themselves subject to change and modification. I think one has to take
all of this into account. That’s all I mean.

That’s a valid question and answer, but it’s non-responsive to my
point.

The goal, if you must Monkey Patch, is to slightly increase the odds
of a clear diagnostic error message when the real library upgrades out
from under the patch.

Sure, but that’s true of all your code. I don’t like to stigmatize
code that does something to the framework itself, which, like all
other code, can be good or bad, well-maintained or not, etc. The
adoption of the term “monkey patch” over the last couple of years is,
I think, unfortunate, since it does tend to stigmatize practices that
in many cases are perfectly reasonable and rational.

In short, I don’t literally append “… but you have to do it well and
make sure it works” to everything I say about Ruby, Rails, or software
in general, but I think it’s kind of understood to be implied :slight_smile:

David

–
Phlip
http://assert2.rubyforge.org/

–
Upcoming Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS, April 14-17 2008, New York City
CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!