Closed nathanhoel closed 9 years ago
The only problem I have with this PR, is that accessing params on request may make users think they can change the params and have it take effect. If they want to change them, they have to use get_params and post_params, which are both already available on the request object because prepare_params
has already been called, splitting params in to the two objects before it gets to send(:_filter_request, ...)
.
So I'm concerned that we're giving people another way to access the params (which may cause confusion with the existing methods) that is less useful than the existing ways. There are ways around this (have params return an object that wraps both attributes, and when setting back on the params object update the main object) but I don't think it's very clear or particularly necessary.
I loved the idea though...
I see what you are saying for sure.
When the params are being parsed into get_params
and post_params
the one problem is not all of the params make it into those objects. Any parameter used to create the url is not put in either object. It is these very params that we need access to inside the before_request
method.
When parsing the parameters we could create a third object with these parameters that were consumed in the url, what do you think of that?
I think that makes sense mate.
Let me know when/if you re-work your PR to be that way.
@nathanhoel did you plan on reworking the PR? Or shall I close this?
We found a work around and so it's probably just not important. I can close since I don't plan on doing anything with it.
For instance makes before_request and after_request methods able to access the params list like this
Without access to params we had to use a regular expression or string manipulation on the
request.url
to find the id in the url.