Populate <select> in .rhtml

[dlehman]

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?

 

[Ben Stephens]

My controller has a "register" action:

=20
def register
@teams =3D Team.find_all
end
=20
In the associated "register.rhtml" view:
=20
<%=3D
options =3D ..?..
select("session", "id", options)
%>
=20
How do I populate the <select> with only the name/id of the available
teams?

Something like:

options =3D []
@teams.each do |team|
options << [team.name, team.id]
end

or=20

options =3D []
@teams.each { |team| options << [team.name, team.id] } #shorter version

Ben

 

[daz]

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

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

 

[Ben Stephens]

At any moment, someone is going to jump in with:

=20
options =3D @teams.map { |team| [team.name, team.id] } # even shorter v= ersion
=20
I can feel it )
=20
=20
daz

That's nice, means you can do
select("session", "id", @teams.map { |team| [team.name, team.id] })
If you want to.

Ben

 

[enspired]

Aren't closures just grand? Check out this blog from Martin Fowler on
closures in Ruby:
http://martinfowler.com/bliki/CollectionClosureMethod.html

 

[Gavin Kistner]

Aren't closures just grand? Check out this blog from Martin Fowler on
closures in Ruby:
http://martinfowler.com/bliki/CollectionClosureMethod.html

FWIW, I believe that Martin uses the term "closure" incorrectly on
that entry, as well as on:
http://martinfowler.com/bliki/Closure.html

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] http://www.artima.com/intv/closures2.html
[3] http://en.wikipedia.org/wiki/Closure_(computer_science)
[4] http://jibbering.com/faq/faq_notes/closures.html

 

[Gavin Kistner]

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

And I have four not-so-great things going for me:
1) I can't count.

 

[Daniel Brockman]

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.)