Yes that works and that is what I am doing now, but it feels like it could
follow the same conventions as the time_ago jquery plugin that was based of
the rails verbiage (while extending it with the suggestion I made above):
https://github.com/rmm5t/jquery-timeago
It is good that we can work
Nokogiri is needed for tests and I don't think tests are often used, at
least they should. I still don't see any reason for doing this even more
because almost all Rails applications use capybara and nokogiri is also a
capybara dependency.
On Tue, Jul 14, 2015 at 10:47 AM iybet...@gmail.com
Thank you for the feedback. Thank you especially to Carlos for pointing
out that I could just include ActiveSupport without ActionView.
I could have left out the personal anecdote--Ryan makes a good point that
the real issue is that nokogiri should not be a dependency when it is
needed by
1) By the same logic, almost all Rails applications use devise, and bcrypt
is a dependency of devise.
2) capybara is not typically a dependency in production
On Tue, Jul 14, 2015 at 11:29 AM, Rafael Mendonça França
rafaelmfra...@gmail.com wrote:
Nokogiri is needed for tests and I don't think
3) rails-api (
https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/api.rb)
is merged into master (though not into 4.2-stable). ApplicationController
ActionController::API would would be a very reasonable use case for
having no need for capybara. As this is going to part
+1
There is even a name for that magic `true` parameter: The Boolean Trap
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
Ufuk Kayserilioglu
On Tue, Jul 14, 2015 at 12:02 AM, Prem Sichanugrist sikand...@gmail.com
wrote:
How do you guys feel about adding support for
I just submitted a PR for this: https://github.com/rails/rails/pull/20883
Thanks everyone for your comment.
-Prem
On Tue, Jul 14, 2015 at 4:13 PM Ufuk Kayserilioglu u...@paralaus.com
wrote:
+1
There is even a name for that magic `true` parameter: The Boolean Trap
I already asked a question about refactoring `record.associations(true)` -
`record.associations(reload: true)` here:
https://groups.google.com/forum/#!topic/rubyonrails-core/f756F2DLuG0
However, Eugene raises an interesting question in the PR
Personally I find the double meaning of #reload a bit confusing for singular
associations, I would expect record.association.reload to reload the current
instance of the target object, but record.association(reload: true) to reload
the association itself. The behavior is different if the
Can someone provide a link to the area of the Rails API or documentation
you are discussing.
On Tue, Jul 14, 2015 at 4:43 PM, Will Bryant will.bry...@gmail.com wrote:
Personally I find the double meaning of #reload a bit confusing for
singular associations, I would expect
thanks
On Tue, Jul 14, 2015 at 4:51 PM, Will Bryant will.bry...@gmail.com wrote:
Search for has_one and has_many on api.rubyonrails.org.
On 15/07/2015, at 11:49 , gerbdla gerb...@gmail.com wrote:
Can someone provide a link to the area of the Rails API or documentation
you are discussing.
Search for has_one and has_many on api.rubyonrails.org
http://api.rubyonrails.org/.
On 15/07/2015, at 11:49 , gerbdla gerb...@gmail.com wrote:
Can someone provide a link to the area of the Rails API or documentation you
are discussing.
On Tue, Jul 14, 2015 at 4:43 PM, Will Bryant
Can't you chain like record.associations(reload: true).where - if you do
reload I think we'd lose that
On Tuesday, July 14, 2015, Prem Sichanugrist sikand...@gmail.com wrote:
I already asked a question about refactoring `record.associations(true)`
- `record.associations(reload: true)` here:
Sounds like an improvement to me Prem.
On Mon, Jul 13, 2015 at 2:02 PM, Prem Sichanugrist sikand...@gmail.com
wrote:
How do you guys feel about adding support for passing `reload: true`
instead of just `true` to force reload the association?
I like the idea of that just because it removes a
14 matches
Mail list logo
