hash / param syntax

[MilesTogoe]

we seem to be getting errors sometimes when using keys with quotes rather than a colon - is there some rule on this ?   Does "params" automatically look for colons ? 

myhash = {"name" => "joe"}  vs  {:name => "joe"}

[Lucas Jones]

Yes -- in Ruby, `:me` is a *symbol*, while `"me"` is just a plain old
string. They can be converted to and from each other (symbol.to_s and
string.intern), but they are not the same.

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

[Alex Chaffee]

Sinatra's params object is a Hash, not the HashWithIndifferentAccess
you may be used to from Rails. However, there seems to be something
clever going on behind the scenes, since both params[:foo] and
params['foo'] return the same value. Try running this:

require 'rubygems'
require 'sinatra'

get "/" do
"#{params.class}: #{params.inspect}<br>" +
"params[:foo] = #{params[:foo]}<br>" +
"params['foo'] = #{params['foo']}<br>"
end

open http://localhost:4567/?foo=bar

and you'll see that even though it's a Hash, you get both :foo and
'foo' returning "bar". So what you're describing may be an actual bug.
Can you reproduce it?

---
Alex Chaffee - al...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

[Ryan Tomayko]

On Sat, Feb 13, 2010 at 1:23 PM, Alex Chaffee <ale...@gmail.com> wrote:
> On Sat, Feb 13, 2010 at 1:10 PM, MilesTogoe <miles...@gmail.com> wrote:
>> we seem to be getting errors sometimes when using keys with quotes rather
>> than a colon - is there some rule on this ?   Does "params" automatically
>> look for colons ?
>>
>> myhash = {"name" => "joe"}  vs  {:name => "joe"}
>>
>
> Sinatra's params object is a Hash, not the HashWithIndifferentAccess
> you may be used to from Rails. However, there seems to be something
> clever going on behind the scenes, since both params[:foo] and
> params['foo'] return the same value. Try running this:
>
> require 'rubygems'
> require 'sinatra'
>
> get "/" do
>  "#{params.class}: #{params.inspect}<br>" +
>  "params[:foo] = #{params[:foo]}<br>" +
>  "params['foo'] = #{params['foo']}<br>"
> end
>
> open http://localhost:4567/?foo=bar
>
> and you'll see that even though it's a Hash, you get both :foo and
> 'foo' returning "bar". So what you're describing may be an actual bug.
> Can you reproduce it?

We use Hash's default value proc to allow symbol or string access to
params. You can see the code that makes this work here:

http://github.com/sinatra/sinatra/blob/30c2ef8/lib/sinatra/base.rb#L533-543

The param keys are stored as strings and there's a slight performance
hit when using symbols.

Thanks,
Ryan

> ---
> Alex Chaffee - al...@cohuman.com - http://alexch.github.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
>

[MilesTogoe]

Okay, it gets messy because we are trying to stuff the hash into Mongodb
using the Ruby driver (I'll copy Kyle Banker in on this)

we create an initial hash var using strings
doc = {"name" => nil, "email" => nil, "active" => true}

then it gets updated with colons (strings were crashing)
doc[:username] => "joe"
doc[:email] => "j...@foo.com"

then we push this to a save method which does:
doc = {}
doc["username"] = params[:username]
doc["email"] = params[:email]
doc["active"] = params[:active]
......
coll.save(doc) # mongo update

=> active does not get updated

I tried to use all strings (no colons) but that gave errors - thus the
confusing mix of colons and strings - something in the sinatra code
seems to want colons

see if this makes any sense and if anyone sees an easy workaround (or
simply a best practice) - if not, I'll try to break out the lib code and
put in the test file to post.

[Alex Chaffee]

> We use Hash's default value proc to allow symbol or string access to
> params. You can see the code that makes this work here:
>
> http://github.com/sinatra/sinatra/blob/30c2ef8/lib/sinatra/base.rb#L533-543

So I was right that there was some cleverness, plus that is hands down
the best link URL i've ever seen.

[MilesTogoe]

okay, we got things working by testing extensively - yeah for ruby testing  - we ended up changing all instances of param colons to string keys - that solved it - somewhere, somehow by having a mixture of string keys and colons we had trouble. 


On 02/14/2010 09:25 AM, Kyle Banker wrote:

1. How does it "crash" when you use strings? String as keys should work fine. You're going to have to provide more info on this. A pastie with a test case would be best.

2. If 'active' isn't being saved, you need to show the exact hash being sent to #save. Again, a test case is best here. 

[Paul Walker]

on a side note, I did notice awhile back that params.delete(:name) did not extract the parameter as excepted and that I had to use the string value params.delete('name')