-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
declared(params) doesn't coerce types in before blocks #1074
Comments
I believe this is the expected behavior, actually. Type coercion is really a type of validation, so if you want a given block to run after coercion has happened, you'd want it to be in the after_validations hook. Granted, that may violate the Principle of Least Surprise a bit, but changing this behavior would be a breaking change. |
Thanks for the tip, I'll change my callbacks. It's reasonable to consider this as part of validation, but there's a couple things about this I'd rate as especially surprising:
|
@iangreenleaf I think you are onto something here, maybe this should be fixed? I mean we should prevent |
Agreed! Either make the method unavailable in this scope, or have it raise an error if run. |
I ran into this issue a bit ago and put together this somewhat sloppy solution for my own fork since I hit this pitfall enough for it to annoy me (I am not a smart guy.)
I don't know the Grape codebase at all, but if anyone more savvy than I feels that this solution is in the general direction of correct, I'll go ahead and fix variable/method names, catch all problem cases (not just the general |
I think a much simpler solution would be to declare |
I have been taking a look at this, and I can't think of any solution better than the one @jrforrest proposes. @dblock which |
There has to be a way to introduce scope into that execution that overrides a method. Probably dynamically. I might get to look into this :) |
Well, I suppose we could further break
This would, of course, raise a NoMethodError, but I suppose you could do something like def declared
raise "This method isn't available until..."
end as a default in I'm personally really not a fan of this approach, but it might be acceptable here since there's already a lot of metaprogramming going on in this code. I don't like extending modules on the fly, but I do agree after reading through I would like to point out that I think this pain is somewhat due to Anyway just let me know what I should do in the short term for this. If the approach above sounds acceptable I don't mind coding it and submitting a PR. |
I think what you propose is a fine solution IMHO. |
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
Sorry 'bout the reference spam. Didn't realize issue references would get picked up on fork and I was force-pushing rebases like mad over there. That PR aught to do it. I would like to know if there's related issues for other filters though so I can address those while I'm at it. |
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
In response to issue ruby-grape#1074 This adds a mechanism by which Grape::DSL::InsideRoute methods may be overriden after certain filters are run. The first problem case of a filter being utilized before it should that necessitated this enhancement is the `#declared` method, which was returning un-coerced params in `before` filters. There may be other problem cases, which may be rectified using this same mechanism.
Thanks @towanda, closing. |
In
before
blocks,declared(params)
doesn't seem to perform the usual type coercion. For example:Strangely, it does still seem to validate in the blocks, as undeclared params are still filtered out. It just doesn't convert the types.
The text was updated successfully, but these errors were encountered: