gmane.comp.lang.ruby.rails.core

Re: Preferred method of dealing with options in final argument hash

Jeremy Evans — 2012-05-17T18:09:50

It also gives different results if options has a default value or a
default proc.

If the default value is expensive to produce, using the block version
of Hash#fetch may be better for performance, as then it will only
produce the expensive value if the options hash doesn't contain the
option.

It's generally considered bad style to modify arguments passed into a
method unless that is the purpose of the method itself.  Using:

  options.reverse_merge!(:length => 30)

or

  options[:length] ||= 30

modifies the options hash, and that's a bad idea IMO.

Jeremy

Re: Preferred method of dealing with options in final argument hash

Donald Ball — 2012-05-17T17:48:22

I would strongly advocate using the Hash#fetch method in general:

options.fetch(:length, 30)

Though it's worth noting it gives different results than the || idiom
for nil and false hash values.

Preferred method of dealing with options in final argument hash

iHiD — 2012-05-17T17:40:07

Hi guys,

I'm wondering what the preferred method of parsing the "options" hash is?

In one file, I've just seen these three different methods:

def foobar(options = {})
  options.reverse_merge!(:length => 30)
  #...
  call_another_method(options[:length])
end

def foobar(options = {})
  options[:length] ||= 30
  #...  
  call_another_method(options[:length])
end

def foobar(options = {})
  length = options[:length] || 30
  #...
  call_another_method(length)
end

I'd like to go through and standardise them, at least in the files I'm 
working on. 

Which is the preferred method?

Thanks,
Jeremy

Update Rails on Rack documentation

Rafael Magaña — 2012-05-17T08:23:10

The Rails on Rack documentation is still using the 
"ActionController::Dispatcher" class but it no longer exists, I can update 
the documentation, I just wanted to discuss what's the best way to do it, 
I've tested with "run Rails.application" as well as with "run 
MyAppName::Application" (just like the generated config.ru file does it), 
what do you think?

So the documentation could end up like this:

Rails.application or MyAppName::Application is the primary Rack application 
object of a Rails application. Any Rack compliant web server should be 
using Rails.application or MyAppName::Application object to serve a Rails 
application.


There's another thing. Just after the text above you can find this:

rails server does the basic job of creating a Rack::Builder object and 
starting the webserver. This is Rails’ equivalent of Rack’s rackup script.


Which is not true, at least it doesn't do it directly, what it does is:

1. It creates a class: class Server < ::Rack::Server
2. The Server#start method ca

Original MySQL Adapter

Erich Menge — 2012-05-17T12:38:52

Just curious, is there a reason the original MySQL adapter gem is
still supported?  Or is it something that could be removed for Rails 4?

Rendering the partials and templates paths on top of them as HTML comments

Rafael Magaña — 2012-05-17T09:34:11

The idea is to make a little bit easier to find the rendered partials and 
templates when you start working in an existing project, I know we can see 
the log but I want something easier, in the log you don't know how the 
partial looks like only the name. Right now I'm doing this:

In 
https://github.com/rails/rails/blob/master/actionpack/lib/action_view/renderer/partial_renderer.rb#L308 I 
add this:

 content = layout.render(view, locals){ content } if layout
content.insert(0, "<!-- Partial Rendered: #{< at >path} -->\n") # <<<<

content


And I get this: 

http://d.pr/i/Og9X


but I'm looking for a better way to do it, and the main goal is to submit a 
patch if people think it's worth it or maybe a little gem, don't know, I'd 
like to have a config option in config/development.rb like this too:
      
          config.action_view.render_template_paths = true

Of course, this is only useful to me in development mode.

Any ideas?

Re: Removing old API functionality from actionpack text helpers

Rafael Mendonça França — 2012-05-17T01:57:52

Please do it.

Removing old API functionality from actionpack text helpers

iHiD — 2012-05-16T20:31:25

I was just reading through some of the actionpack text helpers and noticed 
that a lot of them have messages, such as:

# You can still use <tt>word_wrap</tt> with the old API that accepts the
# +line_width+ as its optional second parameter:
#   word_wrap('Once upon a time', 8)     # => Once upon\na time

As other methods (such as truncate) have now had this old API functionality 
removed, would this be a good time to set a depreciation warning on 
3-2-stable and remove the old functionality from master?

If so, I'm happy to do it.

Thanks,
Jeremy

Re: What is the point of using :format in routes?

Andrew White — 2012-05-15T14:56:17


If I add the functionality that :format at the route level is copied to :constraints and :defaults automatically and fix issue #6304 then that should cover your suggestion - still not sure about caching headers though.


No, this is the correct place to discuss these things rather than polluting the issues tracker.


Andrew White

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-15T14:13:18

Em 15-05-2012 02:01, Andrew White escreveu:

This would be equivalent to caches_page, while I need the authorization 
filters to run.


Thanks, I'll try to find some free time to take a look at how 
caches_action works and will try to issue a pull request if that won't 
demand me too much time.


Please, don't get me wrong. I wasn't trying to say that Rails won't 
allow me to do what I want to. I was just asking if we could try making 
such common setup easier to implement in Rails and avoid duplication.

If we accepted "get '/test/index', format: :json, as: :test_index" to 
just mean that, we'd only need "expire_action :test_index" which reads 
much better and is less error prone. Also we shouldn't need any filters 
as the MIME could be extracted from this kind of routing rule.

So your above example could be written as:

TestApp::Application.routes.draw do
   get 'test/index', :as =>  :index, :format =>  :json
   get 'test/expire', :as =>  :expire
end

class TestController<  ApplicationController
   caches

Re: What is the point of using :format in routes?

Andrew White — 2012-05-15T05:01:16

On 15 May 2012, at 04:02, Rodrigo Rosenfeld Rosas wrote:


Use Cache-Control: public to share cached resources between clients - obviously things like cookies and sessions can't be shared.


The caches_page stores static files that Apache/nginx serve up - Rails doesn't even get hit if it's set up properly. If you meant caches_action then that's just the way things have been historically as it's just a wrapper around fragment caching which obviously doesn't need headers saving. Feel free to investigate the feasibility of adding header support to action caching but be aware that controller filters will still run for a cached action (action caching is an around filter itself) so that things like authentication still work so any changes need to make sure that you don't serve cached private data.


You could exploit the fact that action caching still runs controller filters to set the content_type:

TestApp::Application.routes.draw do
  get 'test/index', :as => :index, :format => /|json/
  get 'test/expire', :as

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-15T03:02:10

Em 14-05-2012 18:22, Andrew White escreveu:

This is different and less useful for my application. That is because 
I'd like to fill the cache only in the first access no matter which 
client did request it first. Until that action is expired, only the 
first client should notice the delay in the first access. All other 
clients should benefit from this first access as well.

Would you mind explain why it is hard to store the headers alongside 
with the body in the caches_page mechanism?


Yeah, but then if I accessed /products in a cached action the returned 
content-type would be text/html, right?

Thanks for your support,
Rodrigo.

Re: What is the point of using :format in routes?

Andrew White — 2012-05-14T21:22:06

On 14 May 2012, at 14:06, Rodrigo Rosenfeld Rosas wrote:


That's a longstanding issue - you may want to look at using HTTP caching instead which does cache headers. Rails 3.2 is pre-configured with Rack::Cache - try removing the action caching code from your controller and look at the API docs for stale?, fresh_when? and expires_in. See also the Rails Guide on caching:

http://guides.rubyonrails.org/caching_with_rails.html#conditional-get-support


You can do that now using an empty option in your regexp:

get '/products' => 'products#index', :format => /|json/

This will match /products and /products.json


Andrew White

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-14T13:06:52

Em 14-05-2012 02:11, Andrew White escreveu:

I was expecting the relevant headers to be cached alongside with the 
body content of the response.


Well, this is great! I don't remember that you said that by using a 
regular expression it would be an enforcement instead of a default. And 
I don't mind that I have to use '/test/caches.json'. At least I know 
that if it is called in any other way the application will respond with 
500 or any other error code.

Thank you very much!


Ah, okay, I guess I got it now.


So, shouldn't it be the opposite? Controller will *cache* and it 
currently *expires*? :)


Okay, makes sense.


Yeah, I had just figured it out from a previous comment of yours in this 
message :)


Thanks! I'll try to figure it out an API that could allow an unformatted 
URL before opening the issue. If I can't come to any suggestion I'll 
open the issue with the API you've just mentioned.

Wouldn't it be possible that "get '/products', format: :json" responded 
to both '/products' and '/products.

Re: What is the point of using :format in routes?

Andrew White — 2012-05-14T05:11:20

On 14 May 2012, at 03:08, Rodrigo Rosenfeld Rosas wrote:


That's because the cache action tries to infer the format from the request but can't because there's no extension or default value for :format. It sets the content_type to the default HTML and when you call render :json it only sets the content_type if it is not already been set.

I'm not sure what you expect Rails to do here - how does it know to fetch the JSON cached version if you're relying on the content_type being set by the render? The whole point of action caching is to avoid calling render.


As I said non-regexp keys are assumed to be defaults - use a regexp to make it only accept JSON:

get 'test/caches', :format => /json/

You'd need to have the format in the url though.


As I said you may want to expire all or some cached action formats - not just the format of the current request and you need to tell it which format somehow.


It makes sense when you look at the tense - caches_action is saying that the controller will cache the action

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-14T02:08:50

Hi Andrew, I'm finally back. And thanks, my day was really nice :) I 
hope you have enjoyed yours as well.

Please take a look at the comments inline.

Em 13-05-2012 12:23, Andrew White escreveu:

Here is the main inconsistent issue I was referring to:

routes.rb:
get 'test/cached', format: false
get 'test/uncached', format: false

class TestController < ApplicationController
   caches_action :cached

   def cached
     render json: 1
   end

   def uncached
     render json: 1
   end
end

curl -I http://localhost:3000/test/uncached 2>/dev/null | grep Content-Type

Content-Type: application/json; charset=utf-8

curl -I http://localhost:3000/test/cached 2>/dev/null | grep Content-Type

Content-Type: text/html; charset=utf-8


I would expect "render json: xxx" to render an 'application/json' 
content-type independent from the :format state. This is true for 
uncached actions but cached actions seems to only take into account the 
value of :format.

Because of that, we get a very verbose route for getting it to

Re: What is the point of using :format in routes?

Andrew White — 2012-05-13T15:23:00


I'm not getting why you think they're inconsistent - there's always a optional format parameter unless you tell it not to add one or you make it non-optional in the route itself.


There are plenty of non-API apps that utilise REST and responds_to


Just use a scope - :format works here as well:

scope :format => false do
  resources :products
end

You could even use a nested scope to wrap your actions that return JSON to add the constraints/defaults.


<example code removed>


The test/expire route needs to be set up in the same way - this works for me:

scope :format => false do
  defaults :format => 'json' do
    get 'test/index', :as => :index
    get 'test/expire', :as => :expire
  end
end


This is the route you get if you have the asset pipeline enabled and none of your applications route's matches.


There's a slight wrinkle here - read and write action caches always adds the :format so your cache file ends with .json but expire_action is essentially a wrapper around url_for so gives a path without

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-13T13:16:58

I was not saying that it wasn't possible to write the proper routes, 
just that they don't seem very consistent.

I would guess that most applications won't be API ones, so many of them 
won't opt for REST and responds_to.

For example, all applications I've been working with for the past decade 
will only need to respond to a single format per action.

That means that if I wanted strict rules to my routes I'd have to write 
them as:

get '/anything', format: false

or

get '/anything.:format' => 'anything#index', constraints: {format: 
/json/}, defaults: {format: :json}

I could use a block for this common option except that not all of my 
actions will return a JSON.

Sometimes I'll just return a "head :ok" for remove actions, for example.

But it is important that Rails always returns the correct content-type 
so that my AJAX callbacks get interpreted correctly.

The only reason I have something like '/anything.json' in some of my 
actions is because I want to cache some of them.

Today is Mother's day in

Re: What is the point of using :format in routes?

Andrew White — 2012-05-13T09:10:25

On 13 May 2012, at 04:10, Rodrigo Rosenfeld Rosas wrote:


Whether you write it with or without :format it ends up being the same route - the mapper checks for the presence of the :format key in the path. The generator adds the :format to make it explicitly visible what's happening.

Some history on why there's an optional format would probably useful here. We used to generate both formatted routes and non-formatted routes, e.g. you'd have formatted_product_path(< at >product, :json) and product_path(< at >product). Upon investigation[1][2] it was discovered that this took up significant amount of memory and was changed to an optional segment[3] in the Rails 2.3 release.


Page caching is explicitly designed to avoid hitting the Rails stack - you need to setup Apache or nginx to serve the cached files from the format-less path with the appropriate content type. Action caching should just avoid the page rendering - if you can reproduce a case where a JSON request is action cached and returns an incorrect content type

Re: What is the point of using :format in routes?

Rodrigo Rosenfeld Rosas — 2012-05-13T03:10:37

Em 12-05-2012 02:36, Michael Koziarski escreveu:

Thanks, Michael, I've already found out the answer, but after having a 
surprise first :)

What I was suggesting is that we changed the generated routes.rb so that 
the Rails 1 style route could be written as

match ':controller(/:action(/:id))'

As well as mentioning and explaining the "format" option, like some of 
these examples:

post '/products/:id.:format' => 'products#show', as: :field, 
constraints: {id: /\d+/} # format is required
post '/products/:id' => 'products#show', format: true, as: :field, 
constraints: {id: /\d+/} # this is equivalent
post '/products/:id.json' => 'products#show', format: :json # it only 
answers to json format
post '/products/:id' => 'products#show', format: :json # the same with a 
shorter URL but still allowing you to cache the result and use the 
correct content-type

But then I decided to test it and I was surprised that it doesn't make 
any difference if you use caches_page.

Also, there are more weird rules with regards

ActiveSupport::TimeWithZone#to_time now returns utc?

tiegz — 2012-05-12T15:19:47

Hello, just wanted to see if anyone else thinks this change from 3.1
is questionable?

https://github.com/rails/rails/commit/7872cc992bac76e976334d0c20649d69aad5652e#activesupport/lib/active_support/time_with_zone.rb-P5

For instance:

Time.zone = current_user.time_zone # set the TZ for the request
puts < at >some_object.created_at # returns created_at in user's TZ
puts < at >some_object.created_at.to_time # returns created_at in UTC

^ Calling to_time (as a precaution, in most instances) used to
preserve the timezone pre-3.1, but now it'll return UTC.

Another reason why this is strange is that Time.new.to_time preserves
the timezone, but TimeWithZone should act like Time.