[Rails-core] [ANN] Rails version 3.2.5 has been released!

[Aaron Patterson]

Good news everyone!  Rails version 3.2.5 has been released.

This version of Rails is a less broken version of 3.2.4!

## What happened with 3.2.4?

A regression was reported in the release candidate.  I reverted that
regression without releasing another release candidate for testing.
This release fixes the original regression along with the error made
during reverting.

## CHANGES

This release only contains a few changes, mainly reverting bad commits.
Please check out the commit list on github:

  https://github.com/rails/rails/compare/v3.2.4...v3.2.5

Thanks to everyone, especially @pixeltrix and @rafaelfranca, for
putting up with me!

<3<3<3

-- 
Aaron Patterson
http://tenderlovemaking.com/


pgpkdAh5Tf1Mz.pgp
Description: PGP signature

Re: [Rails-core] Route helpers in JS/CS assets

[Steve Schwartz]

You're right, I searched my bookmarks for "js rails routes" and that came up, 
my bad. There is another project that also does this, which was on Hacker News 
a while back I think, but I can't remember what it's called.

-- Steve Schwartz


On Thursday, May 31, 2012 at 4:38 PM, Rodrigo Rosenfeld Rosas wrote:

> This only works in Rails console. Not in ERB views.
> 
> Steve, while crossroads.js is unrelated to this request, thank you very much 
> for pointing me out js-routes.
> 
> I'll give it a try soon.
> 
> Cheers,
> Rodrigo.
> 
> Em 31-05-2012 17:33, Pedro Nascimento escreveu: 
> > Try `app.root_path`.
> > 
> > On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas 
> > mailto:rr.ro...@gmail.com)> wrote:
> > > Em 31-05-2012 17 (tel:31-05-2012%2017):11, Steve Schwartz escreveu: 
> > > > There are a couple gems and projects that do this: 
> > > > 
> > > > * https://github.com/railsware/js-routes 
> > > > * http://millermedeiros.github.com/crossroads.js/
> > > > 
> > > > I think this is likely outside the scope of rails core, given that most 
> > > > people doing ajax requests will be using the jquery-ujs or 
> > > > prototype-ujs helpers. 
> > > I don't understand how is jquery-ujs related to this issue. 
> > > 
> > > 
> > > > One of the issues why I would personally not use this is because, in 
> > > > order for it to work, you need to populate your JS with a list of all 
> > > > available routes throughout your app. For my own apps, I'd rather not 
> > > > have a list of all the applications' routes in plain text ready to be 
> > > > exploited. 
> > > I agree. I'm not suggesting that all routes should be exported, but I'd 
> > > like to be able to easily decide which ones to export. 
> > > 
> > > 
> > > > Sure, everything is locked-down and access-controlled, but I still 
> > > > don't necessarily want some random visitor knowing that registered 
> > > > group supervisors moderate their group's content via this URL, and 
> > > > approve members via that URL. And again, all of this could be handled 
> > > > by only serving specific JS URL helpers to specific users, but it ends 
> > > > up creating more work than it saves. 
> > > I'm not sure if you have a proper idea on how much saving is that...
> > > 
> > > Even if the idea of exporting the routes to a JavaScript files is not 
> > > accepted, at least it should be easier to use the routes from an ERB 
> > > asset.
> > > 
> > > "Rails.application.routes.url_helpers.send(:products_path)" is almost the 
> > > same as an unsupported operation...
> > > 
> > > Kind regards,
> > > Rodrigo. 
> > > 
> > > 
> > > > 
> > > > 
> > > > On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas wrote:
> > > > 
> > > > > Are there any reasons why Rails doesn't have any route helpers 
> > > > > available 
> > > > > for the JS/CS assets?
> > > > > 
> > > > > We're doing more and more client-side code and it is very likely that 
> > > > > you'll need to do something like "$.post products_path, params" 
> > > > > somewhere in your code.
> > > > > 
> > > > > Currently for doing that you'd need to create a file like 
> > > > > asset.js.coffee.erb and then do something like:
> > > > > 
> > > > > $.post <%= Rails.application.routes.url_helpers.send(:products_path) 
> > > > > %>, 
> > > > > params
> > > > > 
> > > > > This is not only ugly and impractical, but I also don't want my files 
> > > > > to 
> > > > > be processed with ERB. This is not even possible inside my ECO 
> > > > > templates.
> > > > > 
> > > > > So I decided a while back to create a routes.js.coffee.erb to export 
> > > > > my 
> > > > > named routes in some way to my other scripts. But as I needed more 
> > > > > and 
> > > > > more features it got a lot messy now:
> > > > > 
> > > > > <% h = Rails.application.routes.url_helpers 
> > > > > {
> > > > > sections_json: :json, fields_from_parent: :json_id, move_field: :json,
> > > > > field: :json_id, field_save: :json, remove_field: :html_id,
> > > > > field_aggregates_autocomplete: [:json_id, :data_type],
> > > > > field_dependents_autocomplete: :json_id,
> > > > > field_set_aggregator: [:html_id, :aggregator_id],
> > > > > field_remove_aggregate: :html_id,
> > > > > field_add_dependent: [:html_id, :dependent_id],
> > > > > field_remove_dependent: [:html_id, :dependent_id],
> > > > > section_update: :html_id, section_create: :json,
> > > > > }.each do |named_route, options|
> > > > > options = Array(options)
> > > > > format = options.shift
> > > > > format_options = {}
> > > > > format_options[:format] = :json if format =~ /json/
> > > > > options.push format_options
> > > > > if format =~ /_id/ %>
> > > > > window.<%= named_route %>_path = (id, options)->
> > > > > path = "<%= h.send :"#{named_route}_path", '999', *options 
> > > > > %>".replace('999', id)
> > > > > <% if options.size > 1 %>
> > > > > path = path.replace(k, v) for k, v of options
> > > > > path
> > > > > <% end %>
> > > > > <% else %>
> > > > > window.<%= named_route %>_path = '<%= 

Re: [Rails-core] Route helpers in JS/CS assets

[Rodrigo Rosenfeld Rosas]

This only works in Rails console. Not in ERB views.

Steve, while crossroads.js is unrelated to this request, thank you very 
much for pointing me out js-routes.


I'll give it a try soon.

Cheers,
Rodrigo.

Em 31-05-2012 17:33, Pedro Nascimento escreveu:

Try `app.root_path`.

On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas 
mailto:rr.ro...@gmail.com>> wrote:


Em 31-05-2012 17 :11, Steve Schwartz escreveu:

There are a couple gems and projects that do this:

* https://github.com/railsware/js-routes
* http://millermedeiros.github.com/crossroads.js/

I think this is likely outside the scope of rails core, given
that most people doing ajax requests will be using the jquery-ujs
or prototype-ujs helpers.


I don't understand how is jquery-ujs related to this issue.



One of the issues why I would personally not use this is because,
in order for it to work, you need to populate your JS with a list
of all available routes throughout your app. For my own apps, I'd
rather not have a list of all the applications' routes in plain
text ready to be exploited.


I agree. I'm not suggesting that all routes should be exported,
but I'd like to be able to easily decide which ones to export.



Sure, everything is locked-down and access-controlled, but I
still don't necessarily want some random visitor knowing that
registered group supervisors moderate their group's content via
this URL, and approve members via that URL. And again, all of
this could be handled by only serving specific JS URL helpers to
specific users, but it ends up creating more work than it saves.


I'm not sure if you have a proper idea on how much saving is that...

Even if the idea of exporting the routes to a JavaScript files is
not accepted, at least it should be easier to use the routes from
an ERB asset.

"Rails.application.routes.url_helpers.send(:products_path)" is
almost the same as an unsupported operation...

Kind regards,
Rodrigo.




On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas wrote:


Are there any reasons why Rails doesn't have any route helpers
available
for the JS/CS assets?

We're doing more and more client-side code and it is very likely
that
you'll need to do something like "$.post products_path, params"
somewhere in your code.

Currently for doing that you'd need to create a file like
asset.js.coffee.erb and then do something like:

$.post <%=
Rails.application.routes.url_helpers.send(:products_path) %>,
params

This is not only ugly and impractical, but I also don't want my
files to
be processed with ERB. This is not even possible inside my ECO
templates.

So I decided a while back to create a routes.js.coffee.erb to
export my
named routes in some way to my other scripts. But as I needed
more and
more features it got a lot messy now:

<% h = Rails.application.routes.url_helpers
{
sections_json: :json, fields_from_parent: :json_id, move_field:
:json,
field: :json_id, field_save: :json, remove_field: :html_id,
field_aggregates_autocomplete: [:json_id, :data_type],
field_dependents_autocomplete: :json_id,
field_set_aggregator: [:html_id, :aggregator_id],
field_remove_aggregate: :html_id,
field_add_dependent: [:html_id, :dependent_id],
field_remove_dependent: [:html_id, :dependent_id],
section_update: :html_id, section_create: :json,
}.each do |named_route, options|
options = Array(options)
format = options.shift
format_options = {}
format_options[:format] = :json if format =~ /json/
options.push format_options
if format =~ /_id/ %>
window.<%= named_route %>_path = (id, options)->
path = "<%= h.send :"#{named_route}_path", '999', *options
%>".replace('999', id)
<% if options.size > 1 %>
path = path.replace(k, v) for k, v of options
path
<% end %>
<% else %>
window.<%= named_route %>_path = '<%= h.send
:"#{named_route}_path", format_options %>'
<% end %>
<% end %>


See how to maintain something like this can become complicated?

Couldn't Rails provide an easier built-in way for the named
routes to be
easily exported as JS functions/variables?

This way, instead of each application define their own helpers
for such
a common requirement, an official way would exist and developers
moving
their jobs or projects would be aware where to look for.

I just feel there is some convention missing here.

Cheers,
Rodrigo.



--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google

Re: [Rails-core] Route helpers in JS/CS assets

[Pedro Nascimento]

Try `app.root_path`.

On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas  wrote:

>  Em 31-05-2012 17:11, Steve Schwartz escreveu:
>
> There are a couple gems and projects that do this:
>
>  * https://github.com/railsware/js-routes
> * http://millermedeiros.github.com/crossroads.js/
>
>  I think this is likely outside the scope of rails core, given that most
> people doing ajax requests will be using the jquery-ujs or prototype-ujs
> helpers.
>
>
> I don't understand how is jquery-ujs related to this issue.
>
>
>  One of the issues why I would personally not use this is because, in
> order for it to work, you need to populate your JS with a list of all
> available routes throughout your app. For my own apps, I'd rather not have
> a list of all the applications' routes in plain text ready to be exploited.
>
>
> I agree. I'm not suggesting that all routes should be exported, but I'd
> like to be able to easily decide which ones to export.
>
>
>  Sure, everything is locked-down and access-controlled, but I still don't
> necessarily want some random visitor knowing that registered group
> supervisors moderate their group's content via this URL, and approve
> members via that URL. And again, all of this could be handled by only
> serving specific JS URL helpers to specific users, but it ends up creating
> more work than it saves.
>
>
> I'm not sure if you have a proper idea on how much saving is that...
>
> Even if the idea of exporting the routes to a JavaScript files is not
> accepted, at least it should be easier to use the routes from an ERB asset.
>
> "Rails.application.routes.url_helpers.send(:products_path)" is almost the
> same as an unsupported operation...
>
> Kind regards,
> Rodrigo.
>
>
>
>  On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas wrote:
>
>   Are there any reasons why Rails doesn't have any route helpers
> available
> for the JS/CS assets?
>
>  We're doing more and more client-side code and it is very likely that
> you'll need to do something like "$.post products_path, params"
> somewhere in your code.
>
>  Currently for doing that you'd need to create a file like
> asset.js.coffee.erb and then do something like:
>
>  $.post <%= Rails.application.routes.url_helpers.send(:products_path) %>,
> params
>
>  This is not only ugly and impractical, but I also don't want my files to
> be processed with ERB. This is not even possible inside my ECO templates.
>
>  So I decided a while back to create a routes.js.coffee.erb to export my
> named routes in some way to my other scripts. But as I needed more and
> more features it got a lot messy now:
>
>  <% h = Rails.application.routes.url_helpers
>  {
>  sections_json: :json, fields_from_parent: :json_id, move_field: :json,
>  field: :json_id, field_save: :json, remove_field: :html_id,
>  field_aggregates_autocomplete: [:json_id, :data_type],
>  field_dependents_autocomplete: :json_id,
>  field_set_aggregator: [:html_id, :aggregator_id],
>  field_remove_aggregate: :html_id,
>  field_add_dependent: [:html_id, :dependent_id],
>  field_remove_dependent: [:html_id, :dependent_id],
>  section_update: :html_id, section_create: :json,
>  }.each do |named_route, options|
>  options = Array(options)
>  format = options.shift
>  format_options = {}
>  format_options[:format] = :json if format =~ /json/
>  options.push format_options
>  if format =~ /_id/ %>
>  window.<%= named_route %>_path = (id, options)->
>  path = "<%= h.send :"#{named_route}_path", '999', *options
> %>".replace('999', id)
> <% if options.size > 1 %>
>  path = path.replace(k, v) for k, v of options
>  path
> <% end %>
> <% else %>
>  window.<%= named_route %>_path = '<%= h.send
> :"#{named_route}_path", format_options %>'
> <% end %>
> <% end %>
>
>
>  See how to maintain something like this can become complicated?
>
>  Couldn't Rails provide an easier built-in way for the named routes to be
> easily exported as JS functions/variables?
>
>  This way, instead of each application define their own helpers for such
> a common requirement, an official way would exist and developers moving
> their jobs or projects would be aware where to look for.
>
>  I just feel there is some convention missing here.
>
>  Cheers,
> Rodrigo.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Route helpers in JS/CS assets

[Rodrigo Rosenfeld Rosas]

Em 31-05-2012 17:11, Steve Schwartz escreveu:

There are a couple gems and projects that do this:

* https://github.com/railsware/js-routes
* http://millermedeiros.github.com/crossroads.js/

I think this is likely outside the scope of rails core, given that 
most people doing ajax requests will be using the jquery-ujs or 
prototype-ujs helpers.


I don't understand how is jquery-ujs related to this issue.

One of the issues why I would personally not use this is because, in 
order for it to work, you need to populate your JS with a list of all 
available routes throughout your app. For my own apps, I'd rather not 
have a list of all the applications' routes in plain text ready to be 
exploited.


I agree. I'm not suggesting that all routes should be exported, but I'd 
like to be able to easily decide which ones to export.


Sure, everything is locked-down and access-controlled, but I still 
don't necessarily want some random visitor knowing that registered 
group supervisors moderate their group's content via this URL, and 
approve members via that URL. And again, all of this could be handled 
by only serving specific JS URL helpers to specific users, but it ends 
up creating more work than it saves.


I'm not sure if you have a proper idea on how much saving is that...

Even if the idea of exporting the routes to a JavaScript files is not 
accepted, at least it should be easier to use the routes from an ERB asset.


"Rails.application.routes.url_helpers.send(:products_path)" is almost 
the same as an unsupported operation...


Kind regards,
Rodrigo.



On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas wrote:


Are there any reasons why Rails doesn't have any route helpers available
for the JS/CS assets?

We're doing more and more client-side code and it is very likely that
you'll need to do something like "$.post products_path, params"
somewhere in your code.

Currently for doing that you'd need to create a file like
asset.js.coffee.erb and then do something like:

$.post <%= Rails.application.routes.url_helpers.send(:products_path) %>,
params

This is not only ugly and impractical, but I also don't want my files to
be processed with ERB. This is not even possible inside my ECO templates.

So I decided a while back to create a routes.js.coffee.erb to export my
named routes in some way to my other scripts. But as I needed more and
more features it got a lot messy now:

<% h = Rails.application.routes.url_helpers
{
sections_json: :json, fields_from_parent: :json_id, move_field: :json,
field: :json_id, field_save: :json, remove_field: :html_id,
field_aggregates_autocomplete: [:json_id, :data_type],
field_dependents_autocomplete: :json_id,
field_set_aggregator: [:html_id, :aggregator_id],
field_remove_aggregate: :html_id,
field_add_dependent: [:html_id, :dependent_id],
field_remove_dependent: [:html_id, :dependent_id],
section_update: :html_id, section_create: :json,
}.each do |named_route, options|
options = Array(options)
format = options.shift
format_options = {}
format_options[:format] = :json if format =~ /json/
options.push format_options
if format =~ /_id/ %>
window.<%= named_route %>_path = (id, options)->
path = "<%= h.send :"#{named_route}_path", '999', *options
%>".replace('999', id)
<% if options.size > 1 %>
path = path.replace(k, v) for k, v of options
path
<% end %>
<% else %>
window.<%= named_route %>_path = '<%= h.send
:"#{named_route}_path", format_options %>'
<% end %>
<% end %>


See how to maintain something like this can become complicated?

Couldn't Rails provide an easier built-in way for the named routes to be
easily exported as JS functions/variables?

This way, instead of each application define their own helpers for such
a common requirement, an official way would exist and developers moving
their jobs or projects would be aware where to look for.

I just feel there is some convention missing here.

Cheers,
Rodrigo.



--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Route helpers in JS/CS assets

[Steve Schwartz]

There are a couple gems and projects that do this:

* https://github.com/railsware/js-routes
* http://millermedeiros.github.com/crossroads.js/

I think this is likely outside the scope of rails core, given that most people 
doing ajax requests will be using the jquery-ujs or prototype-ujs helpers.

One of the issues why I would personally not use this is because, in order for 
it to work, you need to populate your JS with a list of all available routes 
throughout your app. For my own apps, I'd rather not have a list of all the 
applications' routes in plain text ready to be exploited. Sure, everything is 
locked-down and access-controlled, but I still don't necessarily want some 
random visitor knowing that registered group supervisors moderate their group's 
content via this URL, and approve members via that URL. And again, all of this 
could be handled by only serving specific JS URL helpers to specific users, but 
it ends up creating more work than it saves. 

-- Steve Schwartz


On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas wrote:

> Are there any reasons why Rails doesn't have any route helpers available 
> for the JS/CS assets?
> 
> We're doing more and more client-side code and it is very likely that 
> you'll need to do something like "$.post products_path, params" 
> somewhere in your code.
> 
> Currently for doing that you'd need to create a file like 
> asset.js.coffee.erb and then do something like:
> 
> $.post <%= Rails.application.routes.url_helpers.send(:products_path) %>, 
> params
> 
> This is not only ugly and impractical, but I also don't want my files to 
> be processed with ERB. This is not even possible inside my ECO templates.
> 
> So I decided a while back to create a routes.js.coffee.erb to export my 
> named routes in some way to my other scripts. But as I needed more and 
> more features it got a lot messy now:
> 
> <% h = Rails.application.routes.url_helpers
> {
> sections_json: :json, fields_from_parent: :json_id, move_field: :json,
> field: :json_id, field_save: :json, remove_field: :html_id,
> field_aggregates_autocomplete: [:json_id, :data_type],
> field_dependents_autocomplete: :json_id,
> field_set_aggregator: [:html_id, :aggregator_id],
> field_remove_aggregate: :html_id,
> field_add_dependent: [:html_id, :dependent_id],
> field_remove_dependent: [:html_id, :dependent_id],
> section_update: :html_id, section_create: :json,
> }.each do |named_route, options|
> options = Array(options)
> format = options.shift
> format_options = {}
> format_options[:format] = :json if format =~ /json/
> options.push format_options
> if format =~ /_id/ %>
> window.<%= named_route %>_path = (id, options)->
> path = "<%= h.send :"#{named_route}_path", '999', *options 
> %>".replace('999', id)
> <% if options.size > 1 %>
> path = path.replace(k, v) for k, v of options
> path
> <% end %>
> <% else %>
> window.<%= named_route %>_path = '<%= h.send 
> :"#{named_route}_path", format_options %>'
> <% end %>
> <% end %>
> 
> 
> See how to maintain something like this can become complicated?
> 
> Couldn't Rails provide an easier built-in way for the named routes to be 
> easily exported as JS functions/variables?
> 
> This way, instead of each application define their own helpers for such 
> a common requirement, an official way would exist and developers moving 
> their jobs or projects would be aware where to look for.
> 
> I just feel there is some convention missing here.
> 
> Cheers,
> Rodrigo.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] [ANN] Rails version 3.2.4 has been released!

[Aaron Patterson]

Good news everyone!  Rails version 3.2.4 has been released.

This release of Rails contains two important security fixes:

  * CVE-2012-2660 Ruby on Rails Active Record Unsafe Query Generation Risk
  * CVE-2012-2661 Ruby on Rails Active Record SQL Injection Vulnerability

It is suggested that all users upgrade immediately.  For more information about
these issues, please see the annoumcenents on the rubyonrails-security
mailing list:

  https://groups.google.com/group/rubyonrails-security

Specifically these announcements:

  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/f1203e3376acec0f
  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/7546a238e1962f59

Other changes for this release can be found in each component's CHANGELOG:

  https://github.com/rails/rails/blob/3-2-stable/actionmailer/CHANGELOG.md
  https://github.com/rails/rails/blob/3-2-stable/actionpack/CHANGELOG.md
  https://github.com/rails/rails/blob/3-2-stable/activemodel/CHANGELOG.md
  https://github.com/rails/rails/blob/3-2-stable/activerecord/CHANGELOG.md
  https://github.com/rails/rails/blob/3-2-stable/activesupport/CHANGELOG.md
  https://github.com/rails/rails/blob/3-2-stable/railties/CHANGELOG.md

All changes can be found here:

  https://github.com/rails/rails/compare/v3.2.3...v3.2.4

I want to give a special thanks to Ben Murphy for responsibly reporting the two
security issues that are fixed in this release.  Thank you very much!

<3<3<3

-- 
Aaron Patterson
http://tenderlovemaking.com/


pgpNpuGB9k58d.pgp
Description: PGP signature

[Rails-core] [ANN] Rails version 3.1.5 has been released!

[Aaron Patterson]

Good news everyone!  Rails version 3.1.5 has been released.

This release of Rails contains two important security fixes:

  * CVE-2012-2660 Ruby on Rails Active Record Unsafe Query Generation Risk
  * CVE-2012-2661 Ruby on Rails Active Record SQL Injection Vulnerability

It is suggested that all users upgrade immediately.  For more information about
these issues, please see the annoumcenents on the rubyonrails-security
mailing list:

  https://groups.google.com/group/rubyonrails-security

Specifically these announcements:

  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/f1203e3376acec0f
  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/7546a238e1962f59

Other changes for this release can be found in each component's CHANGELOG:

  https://github.com/rails/rails/blob/3-1-stable/actionmailer/CHANGELOG.md
  https://github.com/rails/rails/blob/3-1-stable/actionpack/CHANGELOG.md
  https://github.com/rails/rails/blob/3-1-stable/activemodel/CHANGELOG.md
  https://github.com/rails/rails/blob/3-1-stable/activerecord/CHANGELOG.md
  https://github.com/rails/rails/blob/3-1-stable/activesupport/CHANGELOG.md
  https://github.com/rails/rails/blob/3-1-stable/railties/CHANGELOG.md

All changes can be found here:

  https://github.com/rails/rails/compare/v3.1.4...v3.1.5

I want to give a special thanks to Ben Murphy for responsibly reporting the two
security issues that are fixed in this release.  Thank you very much!

<3<3<3

-- 
Aaron Patterson
http://tenderlovemaking.com/


pgpO2Q95H10TR.pgp
Description: PGP signature

[Rails-core] [ANN] Rails version 3.0.13 has been released!

[Aaron Patterson]

Good news everyone!  Rails version 3.0.13 has been released.

This release of Rails contains two important security fixes:

  * CVE-2012-2660 Ruby on Rails Active Record Unsafe Query Generation Risk
  * CVE-2012-2661 Ruby on Rails Active Record SQL Injection Vulnerability

It is suggested that all users upgrade immediately.  For more information about
these issues, please see the annoumcenents on the rubyonrails-security
mailing list:

  https://groups.google.com/group/rubyonrails-security

Specifically these announcements:

  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/f1203e3376acec0f
  
https://groups.google.com/group/rubyonrails-security/browse_thread/thread/7546a238e1962f59

Other changes for this release can be found in each component's CHANGELOG:

  https://github.com/rails/rails/blob/3-0-stable/actionmailer/CHANGELOG
  https://github.com/rails/rails/blob/3-0-stable/actionpack/CHANGELOG
  https://github.com/rails/rails/blob/3-0-stable/activemodel/CHANGELOG
  https://github.com/rails/rails/blob/3-0-stable/activerecord/CHANGELOG
  https://github.com/rails/rails/blob/3-0-stable/activesupport/CHANGELOG
  https://github.com/rails/rails/blob/3-0-stable/railties/CHANGELOG

All changes can be found here:

  https://github.com/rails/rails/compare/v3.0.12...v3.0.13

I want to give a special thanks to Ben Murphy for responsibly reporting the two
security issues that are fixed in this release.  Thank you very much!

<3<3<3

-- 
Aaron Patterson
http://tenderlovemaking.com/


pgphj6xjhmI1D.pgp
Description: PGP signature

Re: [Rails-core] Attribute query methods and semantics

[James B. Byrne]

On Thu, May 31, 2012 09:23, Sam Oliver wrote:
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne
> wrote:
>
>>
>> > I would generate attribute query methods only for boolean
>> attributes.
>>
>> I am not sure that I understand your point, but in Ruby anything
>> that
>> is neither nil nor false is true.  Thus returning the url string, if
>> not nil, is the same as saying that it is true but also allows
>> access
>> to the actual data without having to send another message.
>>
>
> I think Max's point is that "post.visible?" could be read as "post is
> visible?" but "post is url?" carries a different meaning.
>

This really comes down to ones own understanding of English.  Since
visible is a quality of some object one may reasonably infer that
#visible? is synonymous with #is_visible?  This might not actually be
the case of course but the inference is strong.

In the case of #url? an url is not a quality, it is an object in own
right even if its representation is wholly contained within the state
of a container object (i.e. an attribute with a string value). I agree
with the OP that in this case #url? is not good form and that #url is
a superior since it imparts the idea that one should receive a
representation and not simply a boolean.

However, #has_url? or #has_anything? to me would be pointless in Ruby.
 If an object has one then just tell it to provide it and if nil is
returned then it does not.



-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Allen Madsen]

Maybe it is just me, but I don't use features that I don't like in rails,
just like I avoid calling private methods. In that sense, there's nothing
that is preventing anyone from using `post.body.present?` instead of
`post.body?`. My argument would be to let rational programmers decide what
is best for their specific case. If you're on a team, set a style guide
that picks a winner.

Allen Madsen
http://www.allenmadsen.com


On Thu, May 31, 2012 at 11:05 AM, Maksym Melnychok wrote:

> On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>>
>> It's not saving a character. It's that !! is programmer talk, and ? is
>> human talk. Ruby prefers human talk.
>>
>
> well your kung-fu beats my kung-fu here
>
> i just don't think post.url? is talking proper human talk to me, i would
> expect answer to that question to be "no, post is not a url" instead i
> will get "yes, url attribute is not empty".
>
> > I guess Rafael meant another thing. You have boolean fields in
> > PostgreSQL but someone might prefer to use some old ANSI types, like
> > INTEGER for storing such booleans for some reason.
>
> i think that first of all this is rather an edge-case that shouldn't force
> us to go against least surprise principle
>
> second - this directly goes against Steve's assumption that
>
> post = Post.new
> post.id = 0
> assert post.id?
>
> should not fail (it fails because 0 is apparently false.. since when?)
>
> i personally think this smells a lot like PHP and it's non-logical,
> generally ugly and wrong truthiness/falseness checks
>
> On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>>
>> > but if we decide that there doesn't have to be semantical contribution
>> to
>> > your code from using attribute query methods then #{attribute}? is just
>> > a shortcut for !!#{attribute} - so why do we need it in the first
>> place?
>> > saving 1 character is weird goal here.
>>
>> It's not saving a character. It's that !! is programmer talk, and ? is
>> human talk. Ruby prefers human talk.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-core/-/KND68A_wF8sJ.
>
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>
> It's not saving a character. It's that !! is programmer talk, and ? is 
> human talk. Ruby prefers human talk. 
>

well your kung-fu beats my kung-fu here

i just don't think post.url? is talking proper human talk to me, i would 
expect answer to that question to be "no, post is not a url" instead i
will get "yes, url attribute is not empty".

> I guess Rafael meant another thing. You have boolean fields in 
> PostgreSQL but someone might prefer to use some old ANSI types, like 
> INTEGER for storing such booleans for some reason. 

i think that first of all this is rather an edge-case that shouldn't force
us to go against least surprise principle

second - this directly goes against Steve's assumption that 

post = Post.new
post.id = 0
assert post.id?

should not fail (it fails because 0 is apparently false.. since when?)

i personally think this smells a lot like PHP and it's non-logical,
generally ugly and wrong truthiness/falseness checks

On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>
> > but if we decide that there doesn't have to be semantical contribution 
> to 
> > your code from using attribute query methods then #{attribute}? is just 
> > a shortcut for !!#{attribute} - so why do we need it in the first place? 
> > saving 1 character is weird goal here. 
>
> It's not saving a character. It's that !! is programmer talk, and ? is 
> human talk. Ruby prefers human talk. 
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/KND68A_wF8sJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rodrigo Rosenfeld Rosas]

Another way would add another annotation method to ActiveRecord::Base, like:

boolean_field :incomplete, :disabled, :deleted

This would further document the model mapping and would also allow 
better semantics.


Not that I really care about this as I don't even use ActiveRecord ;)

Cheers,
Rodrigo.

Em 31-05-2012 11:56, Rafael Mendonça França escreveu:
And in these cases you don't know if these fields are boolean or not. 
If you are choose to store the visible column as string ["yes", "no] 
so you will not have the query method.


I like this method as it is. For me it is very useful and give me the 
possibility to not care about what is the datatype of the field.


Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca



On Thu, May 31, 2012 at 11:52 AM, Rodrigo Rosenfeld Rosas 
mailto:rr.ro...@gmail.com>> wrote:


Em 31-05-2012 11:48, Maksym Melnychok escreveu:

@ Rafael Mendonça França

legacy databases storage must be concern of corresponding database
adapter, if a field is of boolean type, whatever that means on
storage
level of particular database, that field must be treated as
boolean in rails
on the model level.

i'm not suggesting to drop such functionality for boolean
attributes, only
for non-booleans where #{attribute}? literally makes no sense
when you
read it.

methods count would be decreased because rails would generate
query
method only for boolean attributes.


I guess Rafael meant another thing. You have boolean fields in
PostgreSQL but someone might prefer to use some old ANSI types,
like INTEGER for storing such booleans for some reason.



--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rafael Mendonça França]

And in these cases you don't know if these fields are boolean or not. If
you are choose to store the visible column as string ["yes", "no] so you
will not have the query method.

I like this method as it is. For me it is very useful and give me the
possibility to not care about what is the datatype of the field.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca



On Thu, May 31, 2012 at 11:52 AM, Rodrigo Rosenfeld Rosas <
rr.ro...@gmail.com> wrote:

> Em 31-05-2012 11:48, Maksym Melnychok escreveu:
>
>  @ Rafael Mendonça França
>>
>> legacy databases storage must be concern of corresponding database
>> adapter, if a field is of boolean type, whatever that means on storage
>> level of particular database, that field must be treated as boolean in
>> rails
>> on the model level.
>>
>> i'm not suggesting to drop such functionality for boolean attributes, only
>> for non-booleans where #{attribute}? literally makes no sense when you
>> read it.
>>
>> methods count would be decreased because rails would generate query
>> method only for boolean attributes.
>>
>>
> I guess Rafael meant another thing. You have boolean fields in PostgreSQL
> but someone might prefer to use some old ANSI types, like INTEGER for
> storing such booleans for some reason.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to 
> rubyonrails-core@googlegroups.**com
> .
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@**googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/**
> group/rubyonrails-core?hl=en
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rodrigo Rosenfeld Rosas]

Em 31-05-2012 11:52, Rodrigo Rosenfeld Rosas escreveu:

Em 31-05-2012 11:48, Maksym Melnychok escreveu:

@ Rafael Mendonça França

legacy databases storage must be concern of corresponding database
adapter, if a field is of boolean type, whatever that means on storage
level of particular database, that field must be treated as boolean 
in rails

on the model level.

i'm not suggesting to drop such functionality for boolean attributes, 
only

for non-booleans where #{attribute}? literally makes no sense when you
read it.

methods count would be decreased because rails would generate query
method only for boolean attributes.



I guess Rafael meant another thing. You have boolean fields in 
PostgreSQL but someone might prefer to use some old ANSI types, like 
INTEGER for storing such booleans for some reason.


Actually PG do support the ANSI boolean type. But some will prefer some 
other ANSI type because other databases don't support the boolean type:


http://en.wikipedia.org/wiki/SQL:1999#Boolean_data_types 


--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rodrigo Rosenfeld Rosas]

Em 31-05-2012 11:48, Maksym Melnychok escreveu:

@ Rafael Mendonça França

legacy databases storage must be concern of corresponding database
adapter, if a field is of boolean type, whatever that means on storage
level of particular database, that field must be treated as boolean in 
rails

on the model level.

i'm not suggesting to drop such functionality for boolean attributes, only
for non-booleans where #{attribute}? literally makes no sense when you
read it.

methods count would be decreased because rails would generate query
method only for boolean attributes.



I guess Rafael meant another thing. You have boolean fields in 
PostgreSQL but someone might prefer to use some old ANSI types, like 
INTEGER for storing such booleans for some reason.


--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Steve Klabnik]

> but if we decide that there doesn't have to be semantical contribution to
> your code from using attribute query methods then #{attribute}? is just
> a shortcut for !!#{attribute} - so why do we need it in the first place?
> saving 1 character is weird goal here.

It's not saving a character. It's that !! is programmer talk, and ? is
human talk. Ruby prefers human talk.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

@ Rafael Mendonça França

legacy databases storage must be concern of corresponding database 
adapter, if a field is of boolean type, whatever that means on storage 
level of particular database, that field must be treated as boolean in rails
on the model level.

i'm not suggesting to drop such functionality for boolean attributes, only
for non-booleans where #{attribute}? literally makes no sense when you
read it.

methods count would be decreased because rails would generate query
method only for boolean attributes.

@ Steve Klabnik

syntactically you are correct

but if we decide that there doesn't have to be semantical contribution to 
your code from using attribute query methods then #{attribute}? is just 
a shortcut for !!#{attribute} - so why do we need it in the first place? 
saving 1 character is weird goal here.

if on the other hand we want query methods to provide semantics then
there is obvious conflict with non-boolean fields as semantics there are
different.

On Thursday, May 31, 2012 4:30:20 PM UTC+2, Rafael Mendonça França wrote:
>
> Actually the query attribute method does more than check if the value is 
> present. It is very useful for legacy databases where the user persist 
> boolean values as [0, 1], ["t", "f"], ["true", "false"] and more.
>
> I don't see this being removed from rails or changing your behavior.
>
> Also removing it will not decrease the methods count because we still need 
> to generate it for booleans.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
>
> On Thu, May 31, 2012 at 11:17 AM, Rodrigo Rosenfeld Rosas <
> rr.ro...@gmail.com> wrote:
>
>>  I'd guess methods count is relevant based on this pull request:
>>
>> https://github.com/rails/rails/pull/5763
>>
>> Em 31-05-2012 10:49, Maksym Melnychok escreveu: 
>>
>> absolutely agree with all points. i just didn't know if methods count 
>> argument is relevant at all. imo it's a nice side-effect of proposed
>> change.
>>
>> On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote: 
>>>
>>> I'm -1 on a has_* method
>>>
>>>  If we want to kill ? on non boolean attributes we should encourage 
>>> standard @post.url.blank? and @post.url.present? be used instead. The 
>>> originally proposed change makes sense to me. The question mark character 
>>> adds nice semantics to boolean attributes. I agree it's not clear what 
>>> exactly that would do on non-boolean attributes. Removing the questionable 
>>> methods would help decrease the method count. 
>>>
>>>  Does anyone really need to use: @post.id?
>>>  
>>>   -- 
>>> Richard Schneeman
>>> @schneems 
>>>   
>>> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>>>
>>>  
>>>
>>> On 31 May 2012 14:23, Sam Oliver  wrote:
>>>
>>>  On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 
>>> wrote:
>>>   
>>>  
>>> > I would generate attribute query methods only for boolean attributes.
>>>
>>>  I am not sure that I understand your point, but in Ruby anything that
>>> is neither nil nor false is true.  Thus returning the url string, if
>>> not nil, is the same as saying that it is true but also allows access
>>> to the actual data without having to send another message.
>>>  
>>>
>>>  I think Max's point is that "post.visible?" could be read as "post is 
>>> visible?" but "post is url?" carries a different meaning.
>>>  
>>>
>>>  Maybe have query methods for boolean attributes and prefixed query 
>>> methods for not. e.g.
>>> post.visible?
>>> post.has_url?
>>>
>>> Or maybe leave the currently methods as they are, but add new prefixed 
>>> methods, with different prefixes for boolean methods, e.g.
>>> post.is_visible?
>>> post.has_url?
>>>  
>>>
>>>  
>>>  Sam
>>>   -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Ruby on Rails: Core" group.
>>> To post to this group, send email to 
>>> rubyonrails-core@googlegroups.**com
>>> .
>>> To unsubscribe from this group, send email to 
>>> rubyonrails-core+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit this group at http://groups.google.com/**
>>> group/rubyonrails-core?hl=en
>>> .
>>>   
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Ruby on Rails: Core" group.
>>> To post to this group, send email to 
>>> rubyonrails-core@googlegroups.**com
>>> .
>>> To unsubscribe from this group, send email to 
>>> rubyonrails-core+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit this group at http://groups.google.com/**
>>> group/rubyonrails-core?hl=en
>>> .
>>>   
>>>  
>>>   
>> On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote: 
>>>
>>> I'm -1 on a has_* method
>>>
>>>  If we want to kill ? on non boolean attributes we should encourage 
>>> standard @post.url.blank? and @post.url.present? be used instead. Th

Re: [Rails-core] Attribute query methods and semantics

[Rodrigo Rosenfeld Rosas]

Em 31-05-2012 11:30, Rafael Mendonça França escreveu:
Actually the query attribute method does more than check if the value 
is present. It is very useful for legacy databases where the user 
persist boolean values as [0, 1], ["t", "f"], ["true", "false"] and more.


I don't see this being removed from rails or changing your behavior.


I agree with you on that

Also removing it will not decrease the methods count because we still 
need to generate it for booleans.


It would decrease because they would *only* be generated for boolean fields.

--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rafael Mendonça França]

Actually the query attribute method does more than check if the value is
present. It is very useful for legacy databases where the user persist
boolean values as [0, 1], ["t", "f"], ["true", "false"] and more.

I don't see this being removed from rails or changing your behavior.

Also removing it will not decrease the methods count because we still need
to generate it for booleans.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca



On Thu, May 31, 2012 at 11:17 AM, Rodrigo Rosenfeld Rosas <
rr.ro...@gmail.com> wrote:

>  I'd guess methods count is relevant based on this pull request:
>
> https://github.com/rails/rails/pull/5763
>
> Em 31-05-2012 10:49, Maksym Melnychok escreveu:
>
> absolutely agree with all points. i just didn't know if methods count
> argument is relevant at all. imo it's a nice side-effect of proposed
> change.
>
> On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:
>>
>> I'm -1 on a has_* method
>>
>>  If we want to kill ? on non boolean attributes we should encourage
>> standard @post.url.blank? and @post.url.present? be used instead. The
>> originally proposed change makes sense to me. The question mark character
>> adds nice semantics to boolean attributes. I agree it's not clear what
>> exactly that would do on non-boolean attributes. Removing the questionable
>> methods would help decrease the method count.
>>
>>  Does anyone really need to use: @post.id?
>>
>>   --
>> Richard Schneeman
>> @schneems 
>>
>> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>>
>>
>>
>> On 31 May 2012 14:23, Sam Oliver  wrote:
>>
>>  On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 
>> wrote:
>>
>>
>> > I would generate attribute query methods only for boolean attributes.
>>
>>  I am not sure that I understand your point, but in Ruby anything that
>> is neither nil nor false is true.  Thus returning the url string, if
>> not nil, is the same as saying that it is true but also allows access
>> to the actual data without having to send another message.
>>
>>
>>  I think Max's point is that "post.visible?" could be read as "post is
>> visible?" but "post is url?" carries a different meaning.
>>
>>
>>  Maybe have query methods for boolean attributes and prefixed query
>> methods for not. e.g.
>> post.visible?
>> post.has_url?
>>
>> Or maybe leave the currently methods as they are, but add new prefixed
>> methods, with different prefixes for boolean methods, e.g.
>> post.is_visible?
>> post.has_url?
>>
>>
>>
>>  Sam
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To post to this group, send email to 
>> rubyonrails-core@googlegroups.**com
>> .
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/**
>> group/rubyonrails-core?hl=en
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To post to this group, send email to 
>> rubyonrails-core@googlegroups.**com
>> .
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/**
>> group/rubyonrails-core?hl=en
>> .
>>
>>
>>
> On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:
>>
>> I'm -1 on a has_* method
>>
>>  If we want to kill ? on non boolean attributes we should encourage
>> standard @post.url.blank? and @post.url.present? be used instead. The
>> originally proposed change makes sense to me. The question mark character
>> adds nice semantics to boolean attributes. I agree it's not clear what
>> exactly that would do on non-boolean attributes. Removing the questionable
>> methods would help decrease the method count.
>>
>>  Does anyone really need to use: @post.id?
>>
>>   --
>> Richard Schneeman
>> @schneems 
>>
>> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>>
>>
>>
>> On 31 May 2012 14:23, Sam Oliver  wrote:
>>
>>  On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 
>> wrote:
>>
>>
>> > I would generate attribute query methods only for boolean attributes.
>>
>>  I am not sure that I understand your point, but in Ruby anything that
>> is neither nil nor false is true.  Thus returning the url string, if
>> not nil, is the same as saying that it is true but also allows access
>> to the actual data without having to send another message.
>>
>>
>>  I think Max's point is that "post.visible?" could be read as "post is
>> visible?" but "post is url?" carries a different meaning.
>>
>>
>>  Maybe have query methods for boolean attributes and prefixed query
>> methods for not. e.g.
>> post.visible?
>> post.has_url?
>>
>> Or maybe lea

Re: [Rails-core] Attribute query methods and semantics

[Steve Klabnik]

Not using is_ is idiomatic:
http://devblog.avdi.org/2011/04/07/rspec-is-for-the-literate/ (look
for 'There is a different, but related, effect of using RSpec.')

Every Ruby object is truthy or falsey, and so treating them all as
possibly boolean is 100% okay as far as I'm concerned.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Rodrigo Rosenfeld Rosas]

I'd guess methods count is relevant based on this pull request:

https://github.com/rails/rails/pull/5763

Em 31-05-2012 10:49, Maksym Melnychok escreveu:

absolutely agree with all points. i just didn't know if methods count
argument is relevant at all. imo it's a nice side-effect of proposed
change.

On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:

I'm -1 on a has_* method

If we want to kill ? on non boolean attributes we should encourage
standard @post.url.blank? and @post.url.present? be used instead.
The originally proposed change makes sense to me. The question
mark character adds nice semantics to boolean attributes. I agree
it's not clear what exactly that would do on non-boolean
attributes. Removing the questionable methods would help decrease
the method count.

Does anyone really need to use: @post.id ?

-- 
Richard Schneeman

@schneems 

On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:




On 31 May 2012 14:23, Sam Oliver mailto:s...@samoliver.com>> wrote:

On Thu, May 31, 2012 at 2:12 PM, James B. Byrne
mailto:byrn...@harte-lyne.ca>> wrote:


> I would generate attribute query methods only for boolean
attributes.

I am not sure that I understand your point, but in Ruby
anything that
is neither nil nor false is true.  Thus returning the url
string, if
not nil, is the same as saying that it is true but also allows
access
to the actual data without having to send another message.


I think Max's point is that "post.visible?" could be read as
"post is visible?" but "post is url?" carries a different meaning.


Maybe have query methods for boolean attributes
and prefixed query methods for not. e.g.
post.visible?
post.has_url?

Or maybe leave the currently methods as they are, but add new
prefixed methods, with different prefixes for boolean methods, e.g.
post.is_visible?
post.has_url?


Sam
-- 
You received this message because you are subscribed to the

Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to
rubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
.


-- 
You received this message because you are subscribed to the

Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to
rubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
.



On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:

I'm -1 on a has_* method

If we want to kill ? on non boolean attributes we should encourage
standard @post.url.blank? and @post.url.present? be used instead.
The originally proposed change makes sense to me. The question
mark character adds nice semantics to boolean attributes. I agree
it's not clear what exactly that would do on non-boolean
attributes. Removing the questionable methods would help decrease
the method count.

Does anyone really need to use: @post.id ?

-- 
Richard Schneeman

@schneems 

On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:




On 31 May 2012 14:23, Sam Oliver mailto:s...@samoliver.com>> wrote:

On Thu, May 31, 2012 at 2:12 PM, James B. Byrne
mailto:byrn...@harte-lyne.ca>> wrote:


> I would generate attribute query methods only for boolean
attributes.

I am not sure that I understand your point, but in Ruby
anything that
is neither nil nor false is true.  Thus returning the url
string, if
not nil, is the same as saying that it is true but also allows
access
to the actual data without having to send another message.


I think Max's point is that "post.visible?" could be read as
"post is visible?" but "post is url?" carries a different meaning.


Maybe have query methods for boolean attributes
and prefixed query methods for not. e.g.
post.visible?
post.has_url?

Or maybe leave the currently methods as they are, but add new
prefixed methods, with different prefixes for boolean methods, e.g.
post.is_visible?
post.has_url?



--
You received this message because you are subscribed to the Goo

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

absolutely agree with all points. i just didn't know if methods count
argument is relevant at all. imo it's a nice side-effect of proposed
change.

On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:
>
> I'm -1 on a has_* method
>
> If we want to kill ? on non boolean attributes we should encourage 
> standard @post.url.blank? and @post.url.present? be used instead. The 
> originally proposed change makes sense to me. The question mark character 
> adds nice semantics to boolean attributes. I agree it's not clear what 
> exactly that would do on non-boolean attributes. Removing the questionable 
> methods would help decrease the method count. 
>
> Does anyone really need to use: @post.id?
>
> -- 
> Richard Schneeman
> @schneems 
>
> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:23, Sam Oliver  wrote:
>
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne wrote:
>
>
> > I would generate attribute query methods only for boolean attributes.
>
> I am not sure that I understand your point, but in Ruby anything that
> is neither nil nor false is true.  Thus returning the url string, if
> not nil, is the same as saying that it is true but also allows access
> to the actual data without having to send another message.
>
>
> I think Max's point is that "post.visible?" could be read as "post is 
> visible?" but "post is url?" carries a different meaning.
>
>
> Maybe have query methods for boolean attributes and prefixed query methods 
> for not. e.g.
> post.visible?
> post.has_url?
>
> Or maybe leave the currently methods as they are, but add new prefixed 
> methods, with different prefixes for boolean methods, e.g.
> post.is_visible?
> post.has_url?
>  
>
>
> Sam
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>  
>  
>  
On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote:
>
> I'm -1 on a has_* method
>
> If we want to kill ? on non boolean attributes we should encourage 
> standard @post.url.blank? and @post.url.present? be used instead. The 
> originally proposed change makes sense to me. The question mark character 
> adds nice semantics to boolean attributes. I agree it's not clear what 
> exactly that would do on non-boolean attributes. Removing the questionable 
> methods would help decrease the method count. 
>
> Does anyone really need to use: @post.id?
>
> -- 
> Richard Schneeman
> @schneems 
>
> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:23, Sam Oliver  wrote:
>
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne wrote:
>
>
> > I would generate attribute query methods only for boolean attributes.
>
> I am not sure that I understand your point, but in Ruby anything that
> is neither nil nor false is true.  Thus returning the url string, if
> not nil, is the same as saying that it is true but also allows access
> to the actual data without having to send another message.
>
>
> I think Max's point is that "post.visible?" could be read as "post is 
> visible?" but "post is url?" carries a different meaning.
>
>
> Maybe have query methods for boolean attributes and prefixed query methods 
> for not. e.g.
> post.visible?
> post.has_url?
>
> Or maybe leave the currently methods as they are, but add new prefixed 
> methods, with different prefixes for boolean methods, e.g.
> post.is_visible?
> post.has_url?
>  
>
>
> Sam
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>  
>  
>  

-- 
You received this message because you 

Re: [Rails-core] Attribute query methods and semantics

[Jarrett Meyer]

+1 to Richard. Keep ? for booleans, get rid of the others and use .blank?
and .present? as needed.
--
Jarrett Meyer
Email: jarrettme...@gmail.com
Web: JarrettMeyer.com 
Twitter: @jarrettmeyer 



On Thu, May 31, 2012 at 9:45 AM, Richard Schneeman <
richard.schnee...@gmail.com> wrote:

> I'm -1 on a has_* method
>
> If we want to kill ? on non boolean attributes we should encourage
> standard @post.url.blank? and @post.url.present? be used instead. The
> originally proposed change makes sense to me. The question mark character
> adds nice semantics to boolean attributes. I agree it's not clear what
> exactly that would do on non-boolean attributes. Removing the questionable
> methods would help decrease the method count.
>
> Does anyone really need to use: @post.id?
>
> --
> Richard Schneeman
> @schneems 
>
> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:23, Sam Oliver  wrote:
>
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne wrote:
>
>
> > I would generate attribute query methods only for boolean attributes.
>
> I am not sure that I understand your point, but in Ruby anything that
> is neither nil nor false is true.  Thus returning the url string, if
> not nil, is the same as saying that it is true but also allows access
> to the actual data without having to send another message.
>
>
> I think Max's point is that "post.visible?" could be read as "post is
> visible?" but "post is url?" carries a different meaning.
>
>
> Maybe have query methods for boolean attributes and prefixed query methods
> for not. e.g.
> post.visible?
> post.has_url?
>
> Or maybe leave the currently methods as they are, but add new prefixed
> methods, with different prefixes for boolean methods, e.g.
> post.is_visible?
> post.has_url?
>
>
>
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Richard Schneeman]

I'm -1 on a has_* method

If we want to kill ? on non boolean attributes we should encourage standard 
@post.url.blank? and @post.url.present? be used instead. The originally 
proposed change makes sense to me. The question mark character adds nice 
semantics to boolean attributes. I agree it's not clear what exactly that would 
do on non-boolean attributes. Removing the questionable methods would help 
decrease the method count. 

Does anyone really need to use: @post.id? 

-- 
Richard Schneeman
@schneems (http://twitter.com/schneems)





On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:

> 
> 
> On 31 May 2012 14:23, Sam Oliver  (mailto:s...@samoliver.com)> wrote:
> > On Thu, May 31, 2012 at 2:12 PM, James B. Byrne  > (mailto:byrn...@harte-lyne.ca)> wrote:
> > > 
> > > > I would generate attribute query methods only for boolean attributes.
> > > 
> > > I am not sure that I understand your point, but in Ruby anything that
> > > is neither nil nor false is true.  Thus returning the url string, if
> > > not nil, is the same as saying that it is true but also allows access
> > > to the actual data without having to send another message.
> > 
> > I think Max's point is that "post.visible?" could be read as "post is 
> > visible?" but "post is url?" carries a different meaning. 
> 
> Maybe have query methods for boolean attributes and prefixed query methods 
> for not. e.g.
> post.visible?
> post.has_url?
> 
> Or maybe leave the currently methods as they are, but add new prefixed 
> methods, with different prefixes for boolean methods, e.g.
> post.is_visible?
> post.has_url?
>  
> > 
> > Sam
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Jeremy Walker]

On 31 May 2012 14:23, Sam Oliver  wrote:

> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne wrote:
>
>>
>> > I would generate attribute query methods only for boolean attributes.
>>
>> I am not sure that I understand your point, but in Ruby anything that
>> is neither nil nor false is true.  Thus returning the url string, if
>> not nil, is the same as saying that it is true but also allows access
>> to the actual data without having to send another message.
>>
>
> I think Max's point is that "post.visible?" could be read as "post is
> visible?" but "post is url?" carries a different meaning.
>

Maybe have query methods for boolean attributes and prefixed query methods
for not. e.g.
post.visible?
post.has_url?

Or maybe leave the currently methods as they are, but add new prefixed
methods, with different prefixes for boolean methods, e.g.
post.is_visible?
post.has_url?


>
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Sam Oliver]

On Thu, May 31, 2012 at 2:12 PM, James B. Byrne wrote:

>
> > I would generate attribute query methods only for boolean attributes.
>
> I am not sure that I understand your point, but in Ruby anything that
> is neither nil nor false is true.  Thus returning the url string, if
> not nil, is the same as saying that it is true but also allows access
> to the actual data without having to send another message.
>

I think Max's point is that "post.visible?" could be read as "post is
visible?" but "post is url?" carries a different meaning.

Sam

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

my point is about semantics, not truthiness/falseness of values

post.visible? - is asking post object if it is visible because it has
a flag(boolean attribute) named 'visible'

post.url? - is checking if attribute named 'url' is present or not, and
that is exactly what i find confusing because even though 
syntactically it is identical to flag check, semantically this line looks
like we're asking post object if it is a url which makes no sense.

Regards, Max

On Thursday, May 31, 2012 3:12:21 PM UTC+2, byrnejb wrote:
>
>
> On Thu, May 31, 2012 08:58, Maksym Melnychok wrote: 
> > Does anyone else finds attribute query methods semantically confusing? 
> > 
> > Hi, 
> > 
> > Consider this code: 
> > 
> > post = Post.new(:visible => true, :url => "http://com";) 
> > 
> > if post.visible? 
> >   puts "ima visible!" 
> > end 
> > 
> > if post.url? 
> >   puts "ima url! (wait wat? o_0)" 
> > end 
> > 
> > Does this feel right to you? In case with post.url? i read it as "Hey 
> > post object, are you an url?" which is apparently not what the code 
> > will do. 
> > 
> > So it seems like semantically perfect flag checks go together with 
> > totally confusing(for a reader) way of checking whether an attribute 
> > is present or not. 
> > 
> > I would generate attribute query methods only for boolean attributes. 
>
> I am not sure that I understand your point, but in Ruby anything that 
> is neither nil nor false is true.  Thus returning the url string, if 
> not nil, is the same as saying that it is true but also allows access 
> to the actual data without having to send another message. 
>
> -- 
> ***  E-Mail is NOT a SECURE channel  *** 
> James B. Byrnemailto:byrn...@harte-lyne.ca 
> Harte & Lyne Limited  http://www.harte-lyne.ca 
> 9 Brockley Drive  vox: +1 905 561 1241 
> Hamilton, Ontario fax: +1 905 561 0757 
> Canada  L8E 3C3 
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/0YtbyF6g470J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[James B. Byrne]

On Thu, May 31, 2012 08:58, Maksym Melnychok wrote:
> Does anyone else finds attribute query methods semantically confusing?
>
> Hi,
>
> Consider this code:
>
> post = Post.new(:visible => true, :url => "http://com";)
>
> if post.visible?
>   puts "ima visible!"
> end
>
> if post.url?
>   puts "ima url! (wait wat? o_0)"
> end
>
> Does this feel right to you? In case with post.url? i read it as "Hey
> post object, are you an url?" which is apparently not what the code
> will do.
>
> So it seems like semantically perfect flag checks go together with
> totally confusing(for a reader) way of checking whether an attribute
> is present or not.
>
> I would generate attribute query methods only for boolean attributes.

I am not sure that I understand your point, but in Ruby anything that
is neither nil nor false is true.  Thus returning the url string, if
not nil, is the same as saying that it is true but also allows access
to the actual data without having to send another message.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Route helpers in JS/CS assets

[Rodrigo Rosenfeld Rosas]

Are there any reasons why Rails doesn't have any route helpers available 
for the JS/CS assets?


We're doing more and more client-side code and it is very likely that 
you'll need to do something like "$.post products_path, params" 
somewhere in your code.


Currently for doing that you'd need to create a file like 
asset.js.coffee.erb and then do something like:


$.post <%= Rails.application.routes.url_helpers.send(:products_path) %>, 
params


This is not only ugly and impractical, but I also don't want my files to 
be processed with ERB. This is not even possible inside my ECO templates.


So I decided a while back to create a routes.js.coffee.erb to export my 
named routes in some way to my other scripts. But as I needed more and 
more features it got a lot messy now:


<% h = Rails.application.routes.url_helpers
  {
sections_json: :json, fields_from_parent: :json_id, move_field: :json,
field: :json_id, field_save: :json, remove_field: :html_id,
field_aggregates_autocomplete: [:json_id, :data_type],
field_dependents_autocomplete: :json_id,
field_set_aggregator: [:html_id, :aggregator_id],
field_remove_aggregate: :html_id,
field_add_dependent: [:html_id, :dependent_id],
field_remove_dependent: [:html_id, :dependent_id],
section_update: :html_id, section_create: :json,
  }.each do |named_route, options|
options = Array(options)
format = options.shift
format_options = {}
format_options[:format] = :json if format =~ /json/
options.push format_options
if format =~ /_id/ %>
  window.<%= named_route %>_path = (id, options)->
path = "<%= h.send :"#{named_route}_path", '999', *options 
%>".replace('999', id)

<% if options.size > 1 %>
path = path.replace(k, v) for k, v of options
path
<% end %>
<% else %>
  window.<%= named_route %>_path = '<%= h.send 
:"#{named_route}_path", format_options %>'

<% end %>
<% end %>


See how to maintain something like this can become complicated?

Couldn't Rails provide an easier built-in way for the named routes to be 
easily exported as JS functions/variables?


This way, instead of each application define their own helpers for such 
a common requirement, an official way would exist and developers moving 
their jobs or projects would be aware where to look for.


I just feel there is some convention missing here.

Cheers,
Rodrigo.

--
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

Does anyone else finds attribute query methods semantically confusing?

Hi,

Consider this code:

post = Post.new(:visible => true, :url => "http://com";)

if post.visible?
  puts "ima visible!"
end

if post.url?
  puts "ima url! (wait wat? o_0)"
end

Does this feel right to you? In case with post.url? i read it as "Hey post 
object, are you an url?" which is apparently not what the code will do.

So it seems like semantically perfect flag checks go together with totally 
confusing(for a reader) way of checking whether an attribute is present or 
not.

I would generate attribute query methods only for boolean attributes.

Regards, Max

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/YqYSFrZrLWIJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.