My "teams" table has about 15 fields for each team record. However, I
want to have a <select> tag populated with only the name and id for
each team.
My controller has a "register" action:
def register
@teams = Team.find_all
end
In the associated "register.rhtml" view:
<%=
options = ..?..
select("session", "id", options)
%>
How do I populate the <select> with only the name/id of the available
teams?
My controller has a "register" action:
def register
@teams = Team.find_all
endIn the associated "register.rhtml" view:
<%=
options = ..?..
select("session", "id", options)
%>How do I populate the <select> with only the name/id of the available
teams?
Something like:
options =
@teams.each do |team|
options << [team.name, team.id]
end
or
options =
@teams.each { |team| options << [team.name, team.id] } #shorter version
Ben
Ben Stephens wrote:
Something like:
options =
@teams.each do |team|
options << [team.name, team.id]
endor
options =
@teams.each { |team| options << [team.name, team.id] } #shorter version
At any moment, someone is going to jump in with:
options = @teams.map { |team| [team.name, team.id] } # even shorter version
I can feel it ;))
daz
At any moment, someone is going to jump in with:
options = @teams.map { |team| [team.name, team.id] } # even shorter version
I can feel it ;))
daz
That's nice, means you can do
select("session", "id", @teams.map { |team| [team.name, team.id] })
If you want to.
Ben
Aren't closures just grand? Check out this blog from Martin Fowler on
closures in Ruby:
FWIW, I believe that Martin uses the term "closure" incorrectly on that entry, as well as on:
Ruby's blocks have three great things going for them:
1) They have a very, very simple syntax (and are anonymous)
2) They are first-class functions (can be treated and passed as variables)
3) Ruby's syntax allows blocks to be passed to a method very easily
4) They are closures
A function that is a closure has access to the lexical scoping in which it was defined (the local variables). JavaScript's and Lua's functions are #2 and #4 (first-class closures), but they are certainly not easy to create nor (as easy) to pass. [1]
The article you cite rhapsodizes about features 1-3 of Ruby's blocks, but never uses the fact that they are closures to do its magic. Although I love and grok closures, even Matz has stated that they're not vital to Ruby:
"Yes, and that sharing [between closures and their scope] allows you to do some interesting code demos, but I think it's not that useful in the daily lives of programmers. It doesn't matter that much. The plain copy, like it's done in Java's inner classes for example, works in most cases. But in Ruby closures, I wanted to respect the Lisp culture." [2]
Mostly I'm just being pedantic about the usage of the term "closure". What Martin is describing in his article are called "blocks" in Ruby. I suggest only using the term "closure" when you are specifically describing the features of a lexical closure. For more information, see the Wikipedia entry on closures [3] and this in-depth article on closures in JS [4].
[1] Compare Ruby's: my_array.each{ |el| puts el }
with JavaScript's: my_array.each( function( el ){ alert( el ) } )
or Lua's: each( my_table, function( el ) print( el ) end )
[2] artima - Blocks and Closures in Ruby
[3] Closure (computer programming) - Wikipedia
[4] Javascript Closures
On Aug 2, 2005, at 6:26 AM, enspired wrote:
Aren't closures just grand? Check out this blog from Martin Fowler on
closures in Ruby:
Collection Pipeline
And I have four not-so-great things going for me:
1) I can't count.
On Aug 3, 2005, at 7:23 AM, Gavin Kistner wrote:
Ruby's blocks have three great things going for them:
1) They have a very, very simple syntax (and are anonymous)
2) They are first-class functions (can be treated and passed as variables)
3) Ruby's syntax allows blocks to be passed to a method very easily
4) They are closures
Gavin,
I believe that Martin uses the term "closure" incorrectly
I agree. This is a pet peeve of mine as well. People seem
to think they sound smarter if they always say `closure'
instead of simply `function' or (in Ruby's case) `block'.
A function that is a closure has access to the lexical
scoping in which it was defined (the local variables).
I'd go further and say that a function that refers to its
lexical environment only becomes a closure when that
environment is removed from the stack.
(Otherwise, why not say that every expression that somehow
refers to its environment is a closure?)
In other words, if f and g are functions such that g refers
to some bindings in the lexical scope of f, then a closure
is formed when f returns but a reference to g survives.
Intuitively, I think of a closure as a function wrapped up
with its environment in a bubble floating off the stack.
(Of course, a single function body can be wrapped up into
multiple environments, yielding multiple separate closures.
Similarily, multiple functions can be wrapped up into the
same environment, yielding multiple closures that share a
single bubble.)
--
Daniel Brockman <daniel@brockman.se>
So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.