English | 2013 | ISBN: 978-1-93778-556-7 | 456 Pages | PDF, EPUB | 15 MB
Rails just keeps on changing. Both Rails 3 and 4, as well as Ruby 1.9 and 2.0, bring hundreds of improvements, including new APIs and substantial performance enhancements. The fourth edition of this award-winning classic has been reorganized and refocused so it’s more useful than ever before for developers new to Ruby and Rails.
Rails 4 introduces a number of user-facing changes, and the ebook has been updated to match all the latest changes and new best practices in Rails. This includes full support for Ruby 2.0, controller concerns, Russian Doll caching, strong parameters, Turbolinks, new test and bin directory layouts, and much more.
Ruby on Rails helps you produce high-quality, beautiful-looking web applications quickly. You concentrate on creating the application, and Rails takes care of the details.
Tens of thousands of developers have used this award-winning book to learn Rails. It’s a broad, far-reaching tutorial and reference that’s recommended by the Rails core team. If you’re new to Rails, you’ll get step-by-step guidance. If you’re an experienced developer, this book will give you the comprehensive, insider information you need.
Rails has evolved over the years, and this book has evolved along with it. We still start with a step-by-step walkthrough of building a real application, and in-depth chapters look at the built-in Rails features. This edition now gives new Ruby and Rails users more information on the Ruby language and takes more time to explain key concepts throughout. Best practices on how to apply Rails continue to change, and this edition keeps up. Examples use Concerns, Russian Doll caching, and Turbolinks, and the book focuses throughout on the right way to use Rails. Additionally, this edition now works on Ruby 2.0, a new release of Ruby with substantial functional and performance improvements.
This edition is for Rails4.0 and beyond.
Rails ’ Dependencies
In the JSP world, this is called a scriptlet. Again, many folks will chastise you if they discover you adding code to templates. Ignore them —they’re falling prey to dogma. There ’s nothing wrong with putting code in a template. Just don ’t put too much code in there (and especially don ’t put business logic in a template). As we have already seen, you can use helper methods to successfully resist this temptation.
You can think of the HTML text between code fragments as if each line were being written by a Ruby program. The <%…%> fragments are added to that same program. The HTML is interwoven with the explicit code that you write. As a result, code between <% and %> can affect the output of HTML in the rest of the template.
When you insert a value using <%= …%>, the results will be HTML escaped before being placed directly into the output stream. This is generally what you want.
If, however, the text you ’re substituting contains HTML that you want to be interpreted, this will cause the HTML tags to be escaped —if you create a string containing <em>hello</em> and then substitute it into a template, the user will see <em>hello</em> rather than hello. Rails provides a number of helpers to address this case. The following are a few examples.
The raw() method will cause the string to pass right on through to the output without escaping. This provides the most amount of flexibility, as well as the least amount of security.
The raw() method will HTML escape items in the array that are not HTML safe, join the results with the provided string, and return an HTML-safe result.
Managing Dependencies with Bundler
Dependency management is a deceptively hard problem. During development, you may choose to install updated versions of gems that you depend on. Once you do this, you may find yourself not being able to reproduce problems that occur in production because your runs are picking up different versions of the gems your application depends on. Or perhaps you see problems that don ’t exist in production.
It turns out that dependencies are every bit as important to manage as your application source code or database schemas. If you are developing as part of a team, you want every member of the team to be using the same version of the dependencies. When you deploy, you want to ensure that the version of the dependencies that you tested with are installed on the target machine and are the ones actually used in production.
Interfacing with the Web Server with Rack
Rails runs your application in the context of a web server. So far, we have used two separate web servers: WEBRick, which comes built into the Ruby language, and Phusion Passenger, which integrates with the Apache HTTP web server.
A number of other choices are available, including Mongrel, Lighttpd, Unicorn, and Thin.
Based on this, you might come to the conclusion that Rails has code that allows it to plug into each of these web servers. In earlier releases of Rails, this was true; as of Rails 2.3, this integration was delegated to a gem named Rack.
So, Rails integrates with Rack, Rack integrates with (for example) Passenger, and Passenger integrates with Apache httpd.
Although generally this integration is invisible and taken care of for you when you run the command rails server, a file named config.ru is provided that allows you to directly start your application under Rack.