3 ms·

> Yes. When you write a controller action, you have access to what appears to be a hash called `params`, which is a representation of the parameters that the us

> Yes. When you write a controller action, you have access to what appears to be a hash called `params`, which is a representation of the parameters that the user passed in their request. It could be GET query parameters, or POST parameter data, or a parsed representation of JSON data. So in ActionController::Metal (a superclass of ActionController::Base) you have: def params @_params ||= request.params end which is simply a case of a method in a super class being called in a subclass in your controller action. The rack request object in turn provides: def params @params ||= self.GET.merge(self.POST) rescue EOFError self.GET end The Rack request object itself does the things you describe with GET/POST in each respective method. A few points: * It took me about 25 seconds to find this code. * Making a method available in a subclass doesn't strike me as magic, its just inheritance. * Aside from the aforementioned inheritance "magic", the rest of the things you described come from Rack, not Rails.

sanderjd 14y ago
A few things. The condescending attitude is not necessary. I never claimed that it is somehow impossible or prohibitively difficult to determine how things in Rails work - it is very possible and I do it myself all the time. What I claimed is that Rails has chosen abstraction over obviousness, and gave an example of a place where I believe that is demonstrated. People usually inherit from AC::Base, not AC::Metal, which includes a number of modules, any of which may change the behavior of `params`. You didn't take your expose far enough. As I mentioned in my post, `params` is an already-parsed representation of user data. You traced the call chain a couple of steps, but did not get to the point where parameters are actually parsed. That's fine, I'm not at all interested in the specifics of how parameter parsing works, and I'm certain that you or I could go track it down when necessary. My point is only that it involves a number of layers of abstraction to get there - cataloging those layers is not a very compelling counterpoint.
- alinajaf 14y ago
  How exactly would you parse parameters in a web application framework differently?
  - sanderjd 14y ago
    As always in software, there are lots of options. Here are two: 1. Provide the action with the raw request body as a string. It is then solely responsible for any and all parsing. 2. Provide the action with the raw request body as a string, but provide standard parsing classes that the action can use depending on what they are specifically doing. Both of those solutions would make the parsing code less abstract than the Rails solution, with different trade-offs. I believe this entire thread started because I claimed that Rails has chosen to be further toward the abstraction side of the scale. I can't tell if you really think I am wrong about that, or if you merely think that the choice Rails has made is the right one. If it's the latter, I agree with you, and never claimed otherwise. But it is a choice, and it has trade-offs.

sanderjd 14y ago

A few things. The condescending attitude is not necessary. I never claimed that it is somehow impossible or prohibitively difficult to determine how things in Rails work - it is very possible and I do it myself all the time. What I claimed is that Rails has chosen abstraction over obviousness, and gave an example of a place where I believe that is demonstrated. People usually inherit from AC::Base, not AC::Metal, which includes a number of modules, any of which may change the behavior of `params`. You didn't take your expose far enough. As I mentioned in my post, `params` is an already-parsed representation of user data. You traced the call chain a couple of steps, but did not get to the point where parameters are actually parsed. That's fine, I'm not at all interested in the specifics of how parameter parsing works, and I'm certain that you or I could go track it down when necessary. My point is only that it involves a number of layers of abstraction to get there - cataloging those layers is not a very compelling counterpoint.

alinajaf 14y ago
How exactly would you parse parameters in a web application framework differently?
- sanderjd 14y ago
  As always in software, there are lots of options. Here are two: 1. Provide the action with the raw request body as a string. It is then solely responsible for any and all parsing. 2. Provide the action with the raw request body as a string, but provide standard parsing classes that the action can use depending on what they are specifically doing. Both of those solutions would make the parsing code less abstract than the Rails solution, with different trade-offs. I believe this entire thread started because I claimed that Rails has chosen to be further toward the abstraction side of the scale. I can't tell if you really think I am wrong about that, or if you merely think that the choice Rails has made is the right one. If it's the latter, I agree with you, and never claimed otherwise. But it is a choice, and it has trade-offs.