[Rails-core] Named has_*
It will be nice, if has_* methods will have named option. Example: has_many :foos, named: :boos # equivalent of has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' IMHO it is quite often used feature. Also it will be nice to have scoped option that will allow easy flow with scoped models (i.e. Blog::Posts). -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Named has_*
I also think it is used pretty frequent and may be a good convention. +1 on this, i personally will be glad to see this on trunk. 2014-05-01 19:57 GMT+04:00 Łukasz Niemier luk...@niemier.pl: It will be nice, if has_* methods will have named option. Example: has_many :foos, named: :boos # equivalent of has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' IMHO it is quite often used feature. Also it will be nice to have scoped option that will allow easy flow with scoped models (i.e. Blog::Posts). -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Improvements to Strong Params
I expect params.require(:key) to return its value, not self. I can see that perspective on astonishment, though. In practice, it leads to fluently chained code to set up your params schema: ```ruby def post_params params.require(:post).permit(:subject, :body, ...) end ``` On Wed, Apr 30, 2014 at 7:00 PM, Alexander Trauzzi atrau...@gmail.com wrote: I've just been getting re-acquainted with Rails 4 after spending the past year working in some other frameworks. One thing I noticed are strong parameters which I see as a really great addition! One flaw I've noticed however is in the behaviour of `params.require` which I don't think is 100% user friendly yet. The two major issues I can see are: - It returns a value, when really what it should be doing is returning params to continue with a fluent API - It doesn't accept multiple values (an array) It's been observed in the strong params github issue tracker by several others that this violates the principle of least astonishment by coupling unrelated functionality (returning nested keys) with the enforcement of parameter presence. It also could be argued that people might expect to be able to use it as follows: my_params = params.require(:one, :two, :three).permit(:one, :two, :three, :four) This basically sets up a simple request-specific schema for parameter presence as it begins to travel further into the application's layers. I think the feature of params.require being able to verify the presence of a key and then returning it's contents for nested attributes needlessly couples two pieces of functionality. I typically store all attributes for a request at the root of my `params` and so I never have any nested object data to dereference. It's all at the top, and this results in me having to make multiple separate calls to `params.require` just to verify each one. Which as I'm sure you can guess gets very ugly, very quickly: params.require :one params.require :two params.require :three my_params = params.permit :one, :two, :three, :four -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Improvements to Strong Params
Sure, but keep in mind, you've made an assumption about the schema of the posted variables and imposed it on all consumers of the API. Probably goes beyond astonishment at that point... On Thursday, 1 May 2014 11:20:40 UTC-5, Jeremy Kemper wrote: I expect params.require(:key) to return its value, not self. I can see that perspective on astonishment, though. In practice, it leads to fluently chained code to set up your params schema: ```ruby def post_params params.require(:post).permit(:subject, :body, ...) end ``` On Wed, Apr 30, 2014 at 7:00 PM, Alexander Trauzzi atra...@gmail.comjavascript: wrote: I've just been getting re-acquainted with Rails 4 after spending the past year working in some other frameworks. One thing I noticed are strong parameters which I see as a really great addition! One flaw I've noticed however is in the behaviour of `params.require` which I don't think is 100% user friendly yet. The two major issues I can see are: - It returns a value, when really what it should be doing is returning params to continue with a fluent API - It doesn't accept multiple values (an array) It's been observed in the strong params github issue tracker by several others that this violates the principle of least astonishment by coupling unrelated functionality (returning nested keys) with the enforcement of parameter presence. It also could be argued that people might expect to be able to use it as follows: my_params = params.require(:one, :two, :three).permit(:one, :two, :three, :four) This basically sets up a simple request-specific schema for parameter presence as it begins to travel further into the application's layers. I think the feature of params.require being able to verify the presence of a key and then returning it's contents for nested attributes needlessly couples two pieces of functionality. I typically store all attributes for a request at the root of my `params` and so I never have any nested object data to dereference. It's all at the top, and this results in me having to make multiple separate calls to `params.require` just to verify each one. Which as I'm sure you can guess gets very ugly, very quickly: params.require :one params.require :two params.require :three my_params = params.permit :one, :two, :three, :four -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com javascript:. To post to this group, send email to rubyonra...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Named has_*
On May 1, 2014, at 11:57 AM, Łukasz Niemier luk...@niemier.pl wrote: It will be nice, if has_* methods will have named option. Example: has_many :foos, named: :boos # equivalent of has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' IMHO it is quite often used feature. Also it will be nice to have scoped option that will allow easy flow with scoped models (i.e. Blog::Posts). -1 on this. The first argument of `has_many` is the name you want to refer to the association by (the root name of all the generated methods), not the pluralized model name. It’s sufficiently confusing that I’m pretty sure your expanded example is incorrect; `Foo` is unlikely to have a column named `foo_id`… —Matt Jones signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Rails-core] Improvements to Strong Params
On Apr 30, 2014, at 10:00 PM, Alexander Trauzzi atrau...@gmail.com wrote: I've just been getting re-acquainted with Rails 4 after spending the past year working in some other frameworks. One thing I noticed are strong parameters which I see as a really great addition! One flaw I've noticed however is in the behaviour of `params.require` which I don't think is 100% user friendly yet. The two major issues I can see are: - It returns a value, when really what it should be doing is returning params to continue with a fluent API - It doesn't accept multiple values (an array) It's been observed in the strong params github issue tracker by several others that this violates the principle of least astonishment by coupling unrelated functionality (returning nested keys) with the enforcement of parameter presence. It also could be argued that people might expect to be able to use it as follows: my_params = params.require(:one, :two, :three).permit(:one, :two, :three, :four) What would this specify the expected format *as*? Doing the more usual: params.require(:one).permit(:one, :two, :three, :four) is saying that you expect params like: one: one: (scalar) two: (scalar) three: (scalar) four: (scalar) In the case where `require` takes multiple keys, is it expecting the sub keys in *each* of those? Any of them? This basically sets up a simple request-specific schema for parameter presence as it begins to travel further into the application's layers. I think the feature of params.require being able to verify the presence of a key and then returning it's contents for nested attributes needlessly couples two pieces of functionality. I typically store all attributes for a request at the root of my `params` and so I never have any nested object data to dereference. It's all at the top, and this results in me having to make multiple separate calls to `params.require` just to verify each one. Which as I'm sure you can guess gets very ugly, very quickly: params.require :one params.require :two params.require :three my_params = params.permit :one, :two, :three, :four Does this actually work? I swear I’ve gotten into trouble with calling `permit` on the top-level params hash, since there’s other stuff (:controller, :action, :format, etc) in there… —Matt Jones signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Rails-core] Named has_*
Yes. I have given bad example. It should be only: has_may :boos, class_name: 'Foo' I was writing fast as I encounter the problem, so don't be mad. W dni czw 1 maj, 2014 o 23∶31 użytkownik Matt Jones al2o...@gmail.com napisał: On May 1, 2014, at 11:57 AM, Łukasz Niemier luk...@niemier.pl wrote: It will be nice, if has_* methods will have named option. Example: has_many :foos, named: :boos # equivalent of has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' IMHO it is quite often used feature. Also it will be nice to have scoped option that will allow easy flow with scoped models (i.e. Blog::Posts). -1 on this. The first argument of `has_many` is the name you want to refer to the association by (the root name of all the generated methods), not the pluralized model name. It’s sufficiently confusing that I’m pretty sure your expanded example is incorrect; `Foo` is unlikely to have a column named `foo_id`… —Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Re: CSRF protection in rails 2.3.11
I know this is some serious thread necromancy, and I apologize for that. Google shows this result prominently for this subject. How is this a security flaw? Login only succeeds if the credentials are correct. If someone has credientials, they can login to the site, and I don't see what role forged cross-site requests play in this case. It is a security flaw because an attacker can force a user to login with credentials under his control, and use that to attempt to get a user to give up some form of sensitive information. It's pretty far-fetched, but not completely inconceivable. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Improvements to Strong Params
That's a really good question, but I don't know if presenting a new problem necessarily invalidates the original issue which is that by returning the required value, the API is basically saying strong params has no way of enforcing more than one required value. What if one of the values contained within the returned structure was itself also required? one: (index, required) one: (scalar, required) two: (scalar, not required) I think that rather than trying to accommodate all these legitimate - but complex - edge cases, it'd be smarter to just remove the complexity and push nested validation to somewhere else. I'd be willing to bet there are quite a few people out there misusing the API as it is currently such that at the very least, the name `require` isn't really helping. And again, I'm not even using nested structures. If the idea is to move away from validations coupled with the model (something I agree with), params is going to have to pick up a lot more slack. On Thursday, 1 May 2014 16:36:25 UTC-5, Matt jones wrote: On Apr 30, 2014, at 10:00 PM, Alexander Trauzzi atra...@gmail.comjavascript: wrote: I've just been getting re-acquainted with Rails 4 after spending the past year working in some other frameworks. One thing I noticed are strong parameters which I see as a really great addition! One flaw I've noticed however is in the behaviour of `params.require` which I don't think is 100% user friendly yet. The two major issues I can see are: - It returns a value, when really what it should be doing is returning params to continue with a fluent API - It doesn't accept multiple values (an array) It's been observed in the strong params github issue tracker by several others that this violates the principle of least astonishment by coupling unrelated functionality (returning nested keys) with the enforcement of parameter presence. It also could be argued that people might expect to be able to use it as follows: my_params = params.require(:one, :two, :three).permit(:one, :two, :three, :four) What would this specify the expected format *as*? Doing the more usual: params.require(:one).permit(:one, :two, :three, :four) is saying that you expect params like: one: one: (scalar) two: (scalar) three: (scalar) four: (scalar) In the case where `require` takes multiple keys, is it expecting the sub keys in *each* of those? Any of them? This basically sets up a simple request-specific schema for parameter presence as it begins to travel further into the application's layers. I think the feature of params.require being able to verify the presence of a key and then returning it's contents for nested attributes needlessly couples two pieces of functionality. I typically store all attributes for a request at the root of my `params` and so I never have any nested object data to dereference. It's all at the top, and this results in me having to make multiple separate calls to `params.require` just to verify each one. Which as I'm sure you can guess gets very ugly, very quickly: params.require :one params.require :two params.require :three my_params = params.permit :one, :two, :three, :four Does this actually work? I swear I’ve gotten into trouble with calling `permit` on the top-level params hash, since there’s other stuff (:controller, :action, :format, etc) in there… —Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
