Errata for Agile Web Development with Rails, Third Edition

#41589: ERb is defined as "Embedded Ruby" on p. 18 but is not in the index, please add to index. P2.0 printing April 2009 Version: 2009-4-7, please add this printing to the selection dropdown for Errata as well, this is the paper version I have. Thanks.--M. Roxas

#42012: To produce the sans-serif cart title shown in the "screen-shot", the css for .cart-title needs to be "font: bold 120% sans-serif;". ("120% bold" fails in both Safari 4.0.4 and Firefox 3.5.5)
I believe erratum notification #41977 is incorrect and should be removed - the item price is defined in cart_item.rb to be the product price times the quantity in the cart.--Allan Kinnaird

#42022: For those who did the additional problem of linking using the book image. Here is the AJAX code to perform the same task as the new AJAX button:

<%= link_to_remote (image_tag(product.image_url), :url => { :action => 'add_to_cart',:method => :post, :id => product }) %>

Which is inserted between <div class="entry" and <h3><%= product.title %>--Andrew Szczepanski

#41917: As of the end of section 11.2 the admin_controller function is not working as intended in the case of erroneous logins.

Having a seperate terminal window to view messages I see the flow of login and password unhashed (is this a possible security hole?). Upon proper credentials, the user is sent to the /admin address. As intended. However upon improper credentials, the page is reloaded (intended) but the
flash.now[:notice] = "Invalid user/password combination"
is not kicking in.

I assumed that because of the lack of a views/layouts/admin.html.erb
file, this was occuring.

Upon creation of that file (a simple duplicate of users.html.erb - which in itself is raising a non-DRY issue)
the message appears.

I'm definitely a newbie. This is an interesting bug to leave lying around as an exercise (confirms learning).
But I'm also curious about the security hole and non-DRY issue at hand and resolving it.--Jerome Marchand

#41429: The i18n.t examples are leaving the colon out of the message, for example:
<%= form.label :name, I18n.t('checkout.name') + ":" %>

This should be consider bad i18n, since some languages may and do want to use different character for the colon, or leave it out altogether. It is also a sign for translators that it is used as a label.
--Niklas Laxström

#41924: On the use of UTF-8, HTML and Javascript...

Page 194, section 13.1 states:
"if you do this, just make sure that your editor is configured for UTF-8."

But then when dealing with the localisations for the checkout, the following is presented:
address: "Direcci&oacute;n"
pay_prompt: "Seleccione un m\xC3\xA9todo de pago"
which is a by-product of passing the values via javascript I suspect.

Presently, I literally have a situation where the i18n.rb file has the tilde-n inserted as such and renders (I saved it in UTF-8, no BOM encoding) . The es.yml file has a mix of HTML and hex characters (it does not take kindly to UTF-8 encoding). Three flavours for one objective; dispersive, if not un-DRYish.

This is a point for a someoneSays box to highlight some pitfalls. And maybe suggestions.

Above all, a language file in hexa is rather difficult to read, increases data entry problems, lengthens checking (what will the professional translator do? Upon creation is one thing, upon editing is another! [scent of bad coupling]) and gets moreso as its size increases. Needs to be avoided...--Jerome Marchand

#42273: In the discussion of how to build a callback class and express it throughout all models, I think that a critical question is not addressed:

(1) how do we get this file "sourced" into the Rails runtime. If you put it in lib as a module does it automatically get loaded up? How can we get it to run as the environment boots up. The example source file is given as a stand-alone script.

(2) It appears that we're being encouraged to monkey-patch ActiveRecord::Base. While the ability to do this is one of the amazing joys of Ruby, it might be good to explain why this may or may not be a good idea. Many a tweet has gone out on the difficulty monkeypatching has introduced in code-sharing / debugging.--Steven Harms

#42439: I think that this chapter is off from the general character and tenor of the rest of the book. It feels very much "bolted-on."

The chapter opens strongly, setting up a tri-partite discussion framework and a one-sentence characterization of each of the parts (Prototype, Scriptaculous, RJS). What I consider to be one of the highlights of pragprog books is the way that examples and working assignments are given, and often. This chapter delivers on the example on the second page; however the "how to build up to this" is not given.

Now you MIGHT think this is acceptable (oh you're twenty-someodd chapters in, you can make this example work), but didn't the reader just PAY to have you be verbose and teach? Further, we're learning something new, AJAX. We're learning it without any context, it seems an unfair leap to expect that the reader will be able to execute the harness application flawlessly such that the rest of the lesson might be applied. Perhaps a github link to a baseline project would be helpful if you're committed to not adding text.

Furthermore, no context is given in the code examples. It looks to me like there's some pagination-fu at the base of the view. Where did that chant come from?

I don't expect this chapter to be a be-all-end-all description of Ajax and Rails, but the presentation on this topic in this book has pushed me to buy the ORA "Ajax on Rails" book.

#42401: The description of nested resources in ActiveResource is missing a critical piece. The LineItem model in depot_client is not shown, most importantly the special self.site path with orders/:order_id.

Also the LineItemsController in depot_t does not properly return only the line items for the specified order. Instead it returns all line items for all orders.--Scott Johnson

#41595: The instructions for creating the empty git repository assume git has been installed on the git server. But the reader was not told to install git. "$ git --bare init" will fail if git is not installed. This was found in p3.0, 2009-9-21 PDF.--Jamie Allen