Datasheet

Chapter 1: Building Resources
24
If the second argument is a string or regular expression, then the selector tests to see if there is a tag of
that type whose contents either equal the string or match the regular expression.
The type tag can be augmented in several different ways. Putting a dot after it, as in
form.title ,
checks to see if there s a
form tag that is of the CSS class title . Putting a hash mark after the type
form#form_1 performs a similar test on the DOM ID of the tag. If you re familiar with CSS, you ll note
this syntax is swiped directly from CSS selector syntax. If you add brackets to the type, then you are
checking for an attribute that equals or nearly equals the value specified. The selector
form[action=?]
tests for the existence of a form tag whose action attribute matches the URL specified in the second
argument. The equality test could also use the
*= symbols, indicating that the attribute value contains the
value being tested as a substring, so your test
input[name *= title] would pass if there was an
input tag whose name attribute contains the substring
title . You can similarly use ^= to test that the
value begins with the string or
$= to test if the value ends with the string.
You can do some further specifying with a number of defined pseudo - classes. Many of these allow you
to choose a specific element from the list, such as
form:first - child , form:last - child , form:nth -
child(n)
, and form:nth - last - child(n) , each of which matches only elements of that type that have
the specified relationship with it s parent element.
Finally, you can specify a relationship between two tags. Just putting one tag after the other, as in
form
input
, matches input tags that are some kind of arbitrarily distant descendent of the form tag.
Specifying those relationships can get a bit unwieldy, so you can nest the interior specification inside a
block, as is done in the previous test method. Because of the nested block structure, the test only matches
input tags that are inside a form tag. The specification can also be written form > input , in which case
the
input needs to be a direct child of the form . Alternately form + input indicates that the input
tag is merely after the
form tag in the document, and form ~ input would match the reverse case.
Add it all up, and your test is verifying the existence of a form tag that points to the create action. Inside
that tag, you are testing for inputs with names that include “ title ” and “ servings, ” and text areas that
include the names “ description ” and “ directions. ”
With the view as it is, these tests won t pass, because the view doesn t use
textarea fields for data yet.
Update the
app/views/recipes/new.html.erb code as follows:
< % @title = “Enter a Recipe” % >
< %= error_messages_for :recipe % >
< % form_for(@recipe) do |f| % >
< p >
< b > Recipe Name: < /b > < br / >
< %= f.text_field :title, :class = > “title”, :size = > 48 % >
< /p >
< p >
< b > Serving Size: < /b >
< %= f.text_field :servings, :class = > “input”, :size = > 10 % >
< /p >
< p >
< b > Description (optional): < /b > < br / >
c01.indd 24c01.indd 24 1/30/08 4:02:28 PM1/30/08 4:02:28 PM