Re: [Rails-core] proposal: add option to pretty-print in json renderer

[Rafael Mendonça França]

In Rails 5.1 you will be able to change how the JSON is serialized. See
https://github.com/rails/rails/pull/21496.

On Mon, May 23, 2016 at 7:59 PM Gabriel Burt 
wrote:

> My reading of the action_controller json renderer
> 
>
> add :json do |json, options|
>>   json = json.to_json(options) unless json.kind_of?(String)
>
>
> is that `options` come from the options hash you pass to `render` -- so,
> it's a hash.  But my reading of Hash#to_json
> 
> is that the only argument it accepts is a JSON::State object, not a hash.
> I think that means you can't do anything useful (like enabling
> pretty-print) by passing options to the action_controller json renderer
> (passing `indent: '  '` doesn't work, for instance).
>
> Given that, I'm proposing changing the :json renderer to something more
> like this:
>
> +config_accessor :default_json_pretty
>> +self.default_json_pretty = false if default_json_pretty.nil?
>> +
>>
>  add :json do |json, options|
>> -  json = json.to_json(options) unless json.kind_of?(String)
>> +  unless json.kind_of?(String)
>> +pretty = false
>> +pretty = options[:pretty] unless options[:pretty].nil?
>> +pretty = default_json_pretty if pretty.nil?
>> +
>> +json = json.to_json(pretty ? JSON::PRETTY_STATE_PROTOTYPE : nil)
>> +  end
>>
>
> This would let you specify an app-wide default for `render json: ..`
> pretty printing, but also let you specify it (and override the default) for
> any given render call (with `render json: .., pretty: false`).  And since
> to_json(options) already seems to be ignoring non-JSON::State arguments, it
> shouldn't hurt to not pass them into it anymore.
>
> Did I miss or missunderstand anything in the above?  Does this sound like
> a good idea that I should work up?
>
> Thanks!
>
> Gabriel
>
> --
> 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 https://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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Raise on missing translations (unify controllers and views)

[Rafael Mendonça França]

I'm positive to adding such generic option.

I18n already have the `transalate!` method to raise an error if the
translation is missing maybe we should use it in the Rails wrappers?

On Mon, May 23, 2016 at 7:59 PM Kevin Sjöberg  wrote:

> I'm on a mission to unify the logic for raise_on_missing_translation between
> controllers and views. Currently this is scoped to ActionView. I'm
> proposing that we move the config option to the I18n scope, giving us
> config.i18n.raise_on_missing_translations and thus deprecating 
> config.action_view.raise_on_missing_translations.
> We then update AbstractController#translate and
> TranslationHelper#translate to use the new config option and raise errors
> accordingly.
>
> Since I'm not usually contributing to Rails I might overlook some
> technical or architectural aspects of the problem. Would love some feedback
> on the approach I'm taking. If all sounds good, I will begin working on a
> pull request.
>
> --
> 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 https://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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Change ActionCable Redis default production URL

[dan]

*config/cable.yml*
*Desired implementation*
production:
  adapter: redis
  url: <%= ENV["REDIS_URL"] %>


*Actual implementation*
production:
  adapter: redis 
  url: redis://localhost:6379/1


*Why?*
1) In real life, most instances won't be using a locally hosted version of 
redis
2) Always better to hide info about production
3) Will more easily integrate with third party software


Let me know your thoughts

-- 
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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Change ActionCable Redis default production URL

[dan]

*config/cable.yml*

*Desired implementation*
production:
  adapter: redis
  url: <%= ENV["REDIS_URL"] %>

*Actual implementation*
production:
  adapter: redis
  url: redis://localhost:6379/1


*Why?*
1) In real life, most instances won't be using a locally hosted version of 
redis
2) Always better to hide info about production
3) Will more easily integrate with third party software

Let me know your thoughts

-- 
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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] proposal: add option to pretty-print in json renderer

[Gabriel Burt]

My reading of the action_controller json renderer 


add :json do |json, options|
>   json = json.to_json(options) unless json.kind_of?(String)


is that `options` come from the options hash you pass to `render` -- so, 
it's a hash.  But my reading of Hash#to_json 

 
is that the only argument it accepts is a JSON::State object, not a hash.  
I think that means you can't do anything useful (like enabling 
pretty-print) by passing options to the action_controller json renderer 
(passing `indent: '  '` doesn't work, for instance).

Given that, I'm proposing changing the :json renderer to something more 
like this:

+config_accessor :default_json_pretty
> +self.default_json_pretty = false if default_json_pretty.nil?
> +
>
 add :json do |json, options|
> -  json = json.to_json(options) unless json.kind_of?(String)
> +  unless json.kind_of?(String)
> +pretty = false
> +pretty = options[:pretty] unless options[:pretty].nil?
> +pretty = default_json_pretty if pretty.nil?
> +
> +json = json.to_json(pretty ? JSON::PRETTY_STATE_PROTOTYPE : nil)
> +  end
>

This would let you specify an app-wide default for `render json: ..` pretty 
printing, but also let you specify it (and override the default) for any 
given render call (with `render json: .., pretty: false`).  And since 
to_json(options) already seems to be ignoring non-JSON::State arguments, it 
shouldn't hurt to not pass them into it anymore.

Did I miss or missunderstand anything in the above?  Does this sound like a 
good idea that I should work up?

Thanks!

Gabriel 

-- 
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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Raise on missing translations (unify controllers and views)

[Kevin Sjöberg]

I'm on a mission to unify the logic for raise_on_missing_translation between 
controllers and views. Currently this is scoped to ActionView. I'm 
proposing that we move the config option to the I18n scope, giving us 
config.i18n.raise_on_missing_translations and thus deprecating 
config.action_view.raise_on_missing_translations. 
We then update AbstractController#translate and TranslationHelper#translate 
to use the new config option and raise errors accordingly.

Since I'm not usually contributing to Rails I might overlook some technical 
or architectural aspects of the problem. Would love some feedback on the 
approach I'm taking. If all sounds good, I will begin working on a pull 
request.

-- 
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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Re: Custom type support in ActiveRecord

[Nicholas Firth-McCoy]

I'm definitely interested in this.

If you just want to be able to create enums in an 
`ActiveRecord::Migration`, the SchemaPlus::Enums 
 gem is worth a look.

I think the more interesting thing would to have `ActiveRecord::Enum`backed 
by Postgres, but this raises hard questions about cross-database 
compatibility. It's a bit of a can of worms!

There's also an interesting post here 

 
that talks about some of the issues with the current implementation. I 
believe some of these have been addressed by Rails 5.

On Monday, May 23, 2016 at 8:25:42 AM UTC+10, Mike Dillon wrote:
>
> I'm interested in using Postgres's custom type support with Rails, 
> particularly enumerated types 
> . I see 
> that this topic was previously brought up on this list here 
> , 
> but it did not seem to generate any discussion.
>
> Would there be any interest in supporting Postgres custom enumerated types 
> in ActiveRecord?
>
> As a first pass, I would want to ability to run "CREATE TYPE foo AS 
> ENUM(...)" statements in migrations and have them captured in schema.rb, as 
> well as being able to use custom types alongside native types in my column 
> definitions. I could eventually see it making sense to allow ActiveRecord 
> "enum" declarations to defer to a native database enumeration if it exists, 
> but the "enum" method doesn't seem to have been aligned with the recent 
> upgrades to the type system through the "attribute" keyword and 
> ActiveRecord::Type.
>
> -md
>

-- 
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 https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.