Re: [Rails-core] RFC: Remove support for passing argument to force association reload

[Kevin Deisz]

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  wrote:

> 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 (
> https://github.com/rails/rails/pull/20883#issuecomment-121419119) that it
> might actually make sense to just deprecate the support for
> `record.associations(true)`, and asks user to do
> `record.associations.reload` instead.
>
> I think it make sense, but I want to hear how people think first.
> Internally, it actually does the same thing because the current association
> reader code actually calls `#reload` internally as well.
>
> So, do you think it's a good idea to just deprecate and later remove the
> support for `record.associations(true)` instead?
>
> Thanks,
> Prem
>
> --
> 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.
>


-- 
*Kevin D. Deisz*
*TrialNetworks* - part of DrugDev
Software Developer
383 Elliot Street, Suite G
Newton, MA 02464
+1 617.952.4071 x134 (office)
+1 703.615.0396 (mobile)
kde...@trialnetworks.com

-- 
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] RFC: Remove support for passing argument to force association reload

[gerbdla]

thanks

On Tue, Jul 14, 2015 at 4:51 PM, Will Bryant  wrote:

> Search for has_one and has_many on api.rubyonrails.org.
>
>
> On 15/07/2015, at 11:49 , gerbdla  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 
> wrote:
>
>> 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
>> associated object has changed, for example if the record matching a has_one
>> has changed.
>>
>> In general I think it’s a bad idea for singular association proxy objects
>> to intercept any instance methods.  So I wouldn’t want the has_many
>> associations to do it either, for consistency.
>>
>>
>> On 15/07/2015, at 11:26 , Prem Sichanugrist  wrote:
>>
>> 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 (
>> https://github.com/rails/rails/pull/20883#issuecomment-121419119) that
>> it might actually make sense to just deprecate the support for
>> `record.associations(true)`, and asks user to do
>> `record.associations.reload` instead.
>>
>> I think it make sense, but I want to hear how people think first.
>> Internally, it actually does the same thing because the current association
>> reader code actually calls `#reload` internally as well.
>>
>> So, do you think it's a good idea to just deprecate and later remove the
>> support for `record.associations(true)` instead?
>>
>> Thanks,
>> Prem
>>
>> --
>> 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.
>>
>
>
> --
> 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.
>

-- 
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] RFC: Remove support for passing argument to force association reload

[Will Bryant]

Search for has_one and has_many on api.rubyonrails.org 
.


> On 15/07/2015, at 11:49 , gerbdla  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  > wrote:
> 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 associated object 
> has changed, for example if the record matching a has_one has changed.
> 
> In general I think it’s a bad idea for singular association proxy objects to 
> intercept any instance methods.  So I wouldn’t want the has_many associations 
> to do it either, for consistency.
> 
> 
>> On 15/07/2015, at 11:26 , Prem Sichanugrist > > wrote:
>> 
>> 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 
>> (https://github.com/rails/rails/pull/20883#issuecomment-121419119 
>> ) that it 
>> might actually make sense to just deprecate the support for 
>> `record.associations(true)`, and asks user to do 
>> `record.associations.reload` instead.
>> 
>> I think it make sense, but I want to hear how people think first. 
>> Internally, it actually does the same thing because the current association 
>> reader code actually calls `#reload` internally as well.
>> 
>> So, do you think it's a good idea to just deprecate and later remove the 
>> support for `record.associations(true)` instead?
>> 
>> Thanks,
>> Prem
>> 
>> -- 
>> 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 
> .
> 
> 
> -- 
> 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] RFC: Remove support for passing argument to force association reload

[gerbdla]

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  wrote:

> 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
> associated object has changed, for example if the record matching a has_one
> has changed.
>
> In general I think it’s a bad idea for singular association proxy objects
> to intercept any instance methods.  So I wouldn’t want the has_many
> associations to do it either, for consistency.
>
>
> On 15/07/2015, at 11:26 , Prem Sichanugrist  wrote:
>
> 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 (
> https://github.com/rails/rails/pull/20883#issuecomment-121419119) that it
> might actually make sense to just deprecate the support for
> `record.associations(true)`, and asks user to do
> `record.associations.reload` instead.
>
> I think it make sense, but I want to hear how people think first.
> Internally, it actually does the same thing because the current association
> reader code actually calls `#reload` internally as well.
>
> So, do you think it's a good idea to just deprecate and later remove the
> support for `record.associations(true)` instead?
>
> Thanks,
> Prem
>
> --
> 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.
>

-- 
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] RFC: Remove support for passing argument to force association reload

[Will Bryant]

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 associated object has 
changed, for example if the record matching a has_one has changed.

In general I think it’s a bad idea for singular association proxy objects to 
intercept any instance methods.  So I wouldn’t want the has_many associations 
to do it either, for consistency.


> On 15/07/2015, at 11:26 , Prem Sichanugrist  wrote:
> 
> 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 
> (https://github.com/rails/rails/pull/20883#issuecomment-121419119) that it 
> might actually make sense to just deprecate the support for 
> `record.associations(true)`, and asks user to do `record.associations.reload` 
> instead.
> 
> I think it make sense, but I want to hear how people think first. Internally, 
> it actually does the same thing because the current association reader code 
> actually calls `#reload` internally as well.
> 
> So, do you think it's a good idea to just deprecate and later remove the 
> support for `record.associations(true)` instead?
> 
> Thanks,
> Prem
> 
> -- 
> 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.

[Rails-core] RFC: Remove support for passing argument to force association reload

[Prem Sichanugrist]

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 
(https://github.com/rails/rails/pull/20883#issuecomment-121419119) that it 
might actually make sense to just deprecate the support for 
`record.associations(true)`, and asks user to do 
`record.associations.reload` instead.

I think it make sense, but I want to hear how people think first. 
Internally, it actually does the same thing because the current association 
reader code actually calls `#reload` internally as well.

So, do you think it's a good idea to just deprecate and later remove the 
support for `record.associations(true)` instead?

Thanks,
Prem

-- 
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] Idea: `record.associations(reload: true)` instead of `record.associations(true)`

[Prem Sichanugrist]

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 
wrote:

> +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 
> 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 mystery attribute — you
>> now know why you are passing an argument to that method, instead of passing
>> a magic `true`. However, it's definitely longer to type compared to just
>> `true`.
>>
>> We had some change like this before with `save(false)` where we promoted
>> `save(validate: false)` instead.
>>
>> Do you think it's a good idea? Should I add support for it?
>>
>> -Prem
>>
>> --
>> 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.
>

-- 
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] Idea: `record.associations(reload: true)` instead of `record.associations(true)`

[Ufuk Kayserilioglu]

+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 
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 mystery attribute — you
> now know why you are passing an argument to that method, instead of passing
> a magic `true`. However, it's definitely longer to type compared to just
> `true`.
>
> We had some change like this before with `save(false)` where we promoted
> `save(validate: false)` instead.
>
> Do you think it's a good idea? Should I add support for it?
>
> -Prem
>
> --
> 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] Idea: `record.associations(reload: true)` instead of `record.associations(true)`

[Brian Morearty]

Sounds like an improvement to me Prem.


On Mon, Jul 13, 2015 at 2:02 PM, Prem Sichanugrist 
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 mystery attribute — you
> now know why you are passing an argument to that method, instead of passing
> a magic `true`. However, it's definitely longer to type compared to just
> `true`.
>
> We had some change like this before with `save(false)` where we promoted
> `save(validate: false)` instead.
>
> Do you think it's a good idea? Should I add support for it?
>
> -Prem
>
> --
> 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] Re: Nokogiri adds a lot of weight to ActionView

[Isaac Betesh]

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 of Rails in the next
major release, it seems that Rails applications that only respond_to JSON
will become more common.  While it's still possible to use capybara for
such applications, there are much more lightweight options (such as Webrick
+ Net::HTTP, which I often use instead of capybara for lightweight sinatra
apps).  So even if currently most Rails apps use capybara, a growing number
of them won't with the next release.

On Tue, Jul 14, 2015 at 12:03 PM, Isaac Betesh  wrote:

> 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 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  wrote:
>>
>>> 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 only a small subset of functionality, that often is not used at
>>> all.
>>>
>>> So, rails-core team, are you guys on board?
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "Ruby on Rails: Core" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/rubyonrails-core/TqPPisZ3ttU/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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] Re: Nokogiri adds a lot of weight to ActionView

[Isaac Betesh]

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 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  wrote:
>
>> 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 only a small subset of functionality, that often is not used at
>> all.
>>
>> So, rails-core team, are you guys on board?
>>
>> --
>> 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 a topic in the
> Google Groups "Ruby on Rails: Core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/rubyonrails-core/TqPPisZ3ttU/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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] Re: Nokogiri adds a lot of weight to ActionView

[Rafael Mendonça França]

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  wrote:

> 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 only a small subset of functionality, that often is not used at
> all.
>
> So, rails-core team, are you guys on board?
>
> --
> 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] I18n Relative Time - DateHelpers with Prefixes/Suffixes

[Andrew Turgeon]

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 around it without too much extra code, but it 
seems to force extensions that naturally should flow in with the rest of 
the phrases being constructed.

For example, the Spanish translation for "1 minute ago" would be "hace 1 
minuto" - it has a prefix rather than a suffix to indicate a time in the 
past.

for past times, each language pack would have the two keys

en:
  datetime:
distance_in_words:
  prefix_ago: ""
  suffix_ago: "ago"

es:
  datetime:
distance_in_words:
  prefix_ago: "hace"
  suffix_ago: ""

if we wanted future times, we could do

en:
  datetime:
distance_in_words:
  prefix_from_now: ""
  suffix_from_now: "from now"

es:
  datetime:
distance_in_words:
  prefix_from_now: ""
  suffix_from_now: "a partir de ahora"

On Monday, July 13, 2015 at 6:43:57 PM UTC-4, Carlos Antonio da Silva wrote:
>
> Wouldn't that work with a translation of your own, that receives the "time 
> ago" as an argument that you can interpolate, like this:
>
>
> *translate :time_ago, time: time_ago_in_words(Time.current)*
>
> *# locale*
> *en:*
> *  time_ago: "%{time} ago"*
>
> *pt-BR:*
> *  time_ago: "%{time} atrás"*
>
> *zomg:*
> *  time_ago: "prefix %{time} suffix"*
>
>
> That "just works", without adding any new extension to the 
> method/framework.
>
> Hope that helps.
>
> On Mon, Jul 13, 2015 at 3:23 PM, Andrew Turgeon  > wrote:
>
>> Hi all,
>>
>> I am working on internationalization topics, specifically time 
>> localization, and have ran into an issue that could be a possible feature 
>> inclusion in a future release that I wanted to get others' opinions on.
>>
>> One of the popular formats in English to say a space in time relative to 
>> the present time would be to use "10 minutes ago". Right now, DateHelper 
>>  
>> allows 
>> you to correctly get the text "10 minutes" and then override any of that 
>> language by creating a yml file similar to the default en datetime 
>> translation 
>> .
>>  
>> The part that is missing is "ago" - so let's just add in "ago" into the 
>> override file right?
>>
>> The problem becomes this: If the someone uses the 
>> distance_of_time_in_words without one of the "to" or "from" specified as 
>> Time.now, it doesn't make sense anymore.
>>
>> I want to include "ago" for English but allow that relative time to be 
>> translated properly. I didn't want to include a separate translation key 
>> for "ago" because that could result in improper translation without 
>> context. In addition, other languages have prefixes instead of suffixes 
>> when specifying relative time.
>>
>> My proposal is to add some additional options for the 
>> distance_of_time_in_words method in DateHelper
>> 1) :include_prefix (default: false)
>> 2) :include_suffix (default: false)
>>
>> In the default yml file for datetime distance, there would be additional 
>> keys - :prefix and :suffix
>>
>> For English, suffix would be "ago" and prefix would be "" - this would 
>> allow users to customize not only the language used for the distance of 
>> time in words, but also any prefix or suffix used for the language.
>>
>> Now, if I want my "10 minutes ago", instead of specifying 
>>
>> <%= time_ago_in_words(Time.now) %> ago
>>
>> we can now specify
>>
>> <%= time_ago_in_words(Time.now, :include_prefix => true) %>
>>
>> Thoughts?
>>
>> -Andrew
>>
>>  -- 
>> 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 .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> At.
> Carlos Antonio
>  

-- 
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] I18n Relative Time - DateHelpers with Prefixes/Suffixes

[Andrew Turgeon]

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 around it without too much extra code, but it 
seems to force extensions that naturally should flow in with the rest of 
the phrases being constructed.

For example, the Spanish translation for "1 minute ago" would be "hace 1 
minuto" - it has a prefix rather than a suffix to indicate a time in the 
past.

for past times, each language pack would have the two keys

en:
  datetime:
distance_in_words:
  prefix_ago: ""
  suffix_ago: "ago"

es:
  datetime:
distance_in_words:
  prefix_ago: "hace"
  suffix_ago: ""

if we wanted future times, we could do

en:
  datetime:
distance_in_words:
  prefix_from_now: "from now"
  suffix_from_now: ""

es:
  datetime:
distance_in_words:
  prefix_from_now: ""
  suffix_from_now: "a partir de ahora"

On Monday, July 13, 2015 at 6:43:57 PM UTC-4, Carlos Antonio da Silva wrote:
>
> Wouldn't that work with a translation of your own, that receives the "time 
> ago" as an argument that you can interpolate, like this:
>
>
> *translate :time_ago, time: time_ago_in_words(Time.current)*
>
> *# locale*
> *en:*
> *  time_ago: "%{time} ago"*
>
> *pt-BR:*
> *  time_ago: "%{time} atrás"*
>
> *zomg:*
> *  time_ago: "prefix %{time} suffix"*
>
>
> That "just works", without adding any new extension to the 
> method/framework.
>
> Hope that helps.
>
> On Mon, Jul 13, 2015 at 3:23 PM, Andrew Turgeon  > wrote:
>
>> Hi all,
>>
>> I am working on internationalization topics, specifically time 
>> localization, and have ran into an issue that could be a possible feature 
>> inclusion in a future release that I wanted to get others' opinions on.
>>
>> One of the popular formats in English to say a space in time relative to 
>> the present time would be to use "10 minutes ago". Right now, DateHelper 
>>  
>> allows 
>> you to correctly get the text "10 minutes" and then override any of that 
>> language by creating a yml file similar to the default en datetime 
>> translation 
>> .
>>  
>> The part that is missing is "ago" - so let's just add in "ago" into the 
>> override file right?
>>
>> The problem becomes this: If the someone uses the 
>> distance_of_time_in_words without one of the "to" or "from" specified as 
>> Time.now, it doesn't make sense anymore.
>>
>> I want to include "ago" for English but allow that relative time to be 
>> translated properly. I didn't want to include a separate translation key 
>> for "ago" because that could result in improper translation without 
>> context. In addition, other languages have prefixes instead of suffixes 
>> when specifying relative time.
>>
>> My proposal is to add some additional options for the 
>> distance_of_time_in_words method in DateHelper
>> 1) :include_prefix (default: false)
>> 2) :include_suffix (default: false)
>>
>> In the default yml file for datetime distance, there would be additional 
>> keys - :prefix and :suffix
>>
>> For English, suffix would be "ago" and prefix would be "" - this would 
>> allow users to customize not only the language used for the distance of 
>> time in words, but also any prefix or suffix used for the language.
>>
>> Now, if I want my "10 minutes ago", instead of specifying 
>>
>> <%= time_ago_in_words(Time.now) %> ago
>>
>> we can now specify
>>
>> <%= time_ago_in_words(Time.now, :include_prefix => true) %>
>>
>> Thoughts?
>>
>> -Andrew
>>
>>  -- 
>> 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 .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> At.
> Carlos Antonio
>  

-- 
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.

[Rails-core] Re: Nokogiri adds a lot of weight to ActionView

[iybetesh]

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 only a small subset of functionality, that often is not used at 
all.

So, rails-core team, are you guys on board?

-- 
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.