adding to params hash

rubyonrails-talk
1

my form is passing back turing_confirmation, I have the turing in a session variable. is this the correct way to get the turing into the params hash?

params[:accounts]['turing'] = session['turing']

Model ============================================   validates_confirmation_of :turing

Controller =========================================

  def create     debugger     cookies.delete :auth_token     params[:accounts][:turing] = session['turing']     # protects against session fixation attacks, wreaks havoc with     # request forgery protection.     # uncomment at your own risk     # reset_session     @accounts = Accounts.new(params[:accounts])

    @accounts.save!       self.current_accounts = @accounts       redirect_back_or_default('/')       flash[:notice] = "Thanks for signing up!"   rescue ActiveRecord::RecordInvalid     render :action => 'new'   end

2

I usually use params.merge.

3

could you show the newbie what that would look like? :>

4

It's almost what you already had:

params[:account].merge( :turing => session[:turing] )

Helps one get around that false sense of encapsulation in Ruby/Rails.

5

Hmmm still now workie.. and i can see that session['turing'] is correct! and matches turing_confirmation in the debugger

6

Still not working. and it seems like the params hash cannot be modified. am i doing it wrong?

class AccountsController < ApplicationController   # render new.rhtml   def new

  end

  def create     debugger     cookies.delete :auth_token # params[:accounts]['turing'] = session['turing']     params[:accounts].merge 'turing' => session['turing']

    puts params[:accounts]     # protects against session fixation attacks, wreaks havoc with     # request forgery protection.     # uncomment at your own risk     # reset_session     @accounts = Accounts.new(params[:accounts])

    @accounts.save!       self.current_accounts = @accounts       redirect_back_or_default('/')       flash[:notice] = "Thanks for signing up!"   rescue ActiveRecord::RecordInvalid     render :action => 'new'   end   def updateturing     render( :partial => "createturing" )   end end

7

Still not working. and it seems like the params hash cannot be modified.

I modify it all the time with no problems. *shrug*

am i doing it wrong?     params[:accounts].merge 'turing' => session['turing']

Looks fine to me.

8

Based on my problem of trying to merge params into another hash, and the very interesting question raised by Mark Wilden, maybe the problem is related how you are keying your hash. I was trying to merge params into a hash keyed with symbols, and it didn't work. But when I changed the keys to strings, it did work. So instead of

params[:accounts].merge 'turing' => session['turing']

try

params['accounts'.merge!({'turing' => session['turing'})

Also notice the bang on merge! If that doesn't work, try different possibilities with strings versus symbols.

Phillip

9

This is a standard Ruby-ism :string and 'string' are not the same thing. The leading colon makes it into a Symbol, which is converted into a unique integer behind the scenes. This makes it useful for hashes, because you can use this value directly for the hash instead of having to process it into some kind of key the way you would if it were a String.

I think the convention is that the top-level things in params (e.g. the model name) use Symbols and the lower-level stuff (as in the form arguments) are indexed with strings. It doesn't matter which you use, as long as you are consistent, for example you could use Symbols in your session hash.

String has to_sym and Symbol has to_s so you can get from one to the other easily.

I feel your pain too guys, becuase I went through this one myself a couple of months ago, but I was parsing XML. This is why XmlSimple has the KeyToSymbol argument, as I discovered after running in circles for a while.

HTH

10

Merge method will return a new array unless you specify like,

params = params[:accounts].merge( :turing => session[:turing] )

if it is not working still, you will have try with a different variable name.

11

I'm not sure your statement about it not mattering which you use is entirely accurate. I was reading an article about this (can't remember where), and strings can have a significantly bigger impact on memory usage because each one is a completely separate identifier and therefore has its own memory space. The rule of thumb that I read (and have decided to adopt) is: if you care about the content of the thing, use a string; if it's just an identifier, use a symbol. I'm going through my entire application changing all strings to symbols where I can, and it's turning out to be most places.

As for convention, so far all of the Rails code I've looked at makes almost exclusive use of symbols. In fact, now that I think about it, I can't recall seeing the use of a string. But I haven't scoured every line of Rails either. The easier use of symbols is why they created HashWithIndifferentAccess, which is what params is.

Peace, Phillip

12

I'm not sure your statement about it not mattering which you use is entirely accurate. I was reading an article about this (can't remember where), and strings can have a significantly bigger impact on memory usage because each one is a completely separate identifier and therefore has its own memory space. The rule of thumb that I

1 == 1 # true "some string" == "some string" # false :some_symbol == :some_symbol # true

this help anyone figure out what a symbol is? :wink: (tip - think about '==' in terms of where the data is located in the memory)

13

I'm not sure your statement about it not mattering which you use is entirely accurate. I was reading an article about this (can't remember where), and strings can have a significantly bigger impact on memory usage because each one is a completely separate identifier and therefore has its own memory space. The rule of thumb that I

1 == 1 # true "some string" == "some string" # false :some_symbol == :some_symbol # true

Except that

irb(main):001:0> "some string" == "some string" => true

The equal? method is probably what you were thinking of (since == on
string is a string comparison not an object id comparison or anything
like that)

Fred