RubyGems - rails - Versions diffs - 4.1.4 → 6.0.0 - Mend

rails 4.1.4 → 6.0.0

Potentially problematic release.

This version of rails might be problematic. Click here for more details.

Files changed (284) hide show

data/guides/source/rails_application_templates.md DELETED Viewed

@@ -1,248 +0,0 @@
-Rails Application Templates
-===========================
-Application templates are simple Ruby files containing DSL for adding gems/initializers etc. to your freshly created Rails project or an existing Rails project.
-After reading this guide, you will know:
-* How to use templates to generate/customize Rails applications.
-* How to write your own reusable application templates using the Rails template API.
---------------------------------------------------------------------------------
-Usage
------
-To apply a template, you need to provide the Rails generator with the location of the template you wish to apply using the -m option. This can either be a path to a file or a URL.
-```bash
-$ rails new blog -m ~/template.rb
-$ rails new blog -m http://example.com/template.rb
-```
-You can use the rake task `rails:template` to apply templates to an existing Rails application. The location of the template needs to be passed in to an environment variable named LOCATION. Again, this can either be path to a file or a URL.
-```bash
-$ bin/rake rails:template LOCATION=~/template.rb
-$ bin/rake rails:template LOCATION=http://example.com/template.rb
-```
-Template API
-------------
-The Rails templates API is easy to understand. Here's an example of a typical Rails template:
-```ruby
-# template.rb
-generate(:scaffold, "person name:string")
-route "root to: 'people#index'"
-rake("db:migrate")
-git :init
-git add: "."
-git commit: %Q{ -m 'Initial commit' }
-```
-The following sections outline the primary methods provided by the API:
-### gem(*args)
-Adds a `gem` entry for the supplied gem to the generated application's `Gemfile`.
-For example, if your application depends on the gems `bj` and `nokogiri`:
-```ruby
-gem "bj"
-gem "nokogiri"
-```
-Please note that this will NOT install the gems for you and you will have to run `bundle install` to do that.
-```bash
-bundle install
-```
-### gem_group(*names, &block)
-Wraps gem entries inside a group.
-For example, if you want to load `rspec-rails` only in the `development` and `test` groups:
-```ruby
-gem_group :development, :test do
-  gem "rspec-rails"
-end
-```
-### add_source(source, options = {})
-Adds the given source to the generated application's `Gemfile`.
-For example, if you need to source a gem from `"http://code.whytheluckystiff.net"`:
-```ruby
-add_source "http://code.whytheluckystiff.net"
-```
-### environment/application(data=nil, options={}, &block)
-Adds a line inside the `Application` class for `config/application.rb`.
-If `options[:env]` is specified, the line is appended to the corresponding file in `config/environments`.
-```ruby
-environment 'config.action_mailer.default_url_options = {host: "http://yourwebsite.example.com"}', env: 'production'
-```
-A block can be used in place of the `data` argument.
-### vendor/lib/file/initializer(filename, data = nil, &block)
-Adds an initializer to the generated application's `config/initializers` directory.
-Let's say you like using `Object#not_nil?` and `Object#not_blank?`:
-```ruby
-initializer 'bloatlol.rb', <<-CODE
-  class Object
-    def not_nil?
-      !nil?
-    end
-    def not_blank?
-      !blank?
-    end
-  end
-CODE
-```
-Similarly, `lib()` creates a file in the `lib/` directory and `vendor()` creates a file in the `vendor/` directory.
-There is even `file()`, which accepts a relative path from `Rails.root` and creates all the directories/files needed:
-```ruby
-file 'app/components/foo.rb', <<-CODE
-  class Foo
-  end
-CODE
-```
-That'll create the `app/components` directory and put `foo.rb` in there.
-### rakefile(filename, data = nil, &block)
-Creates a new rake file under `lib/tasks` with the supplied tasks:
-```ruby
-rakefile("bootstrap.rake") do
-  <<-TASK
-    namespace :boot do
-      task :strap do
-        puts "i like boots!"
-      end
-    end
-  TASK
-end
-```
-The above creates `lib/tasks/bootstrap.rake` with a `boot:strap` rake task.
-### generate(what, *args)
-Runs the supplied rails generator with given arguments.
-```ruby
-generate(:scaffold, "person", "name:string", "address:text", "age:number")
-```
-### run(command)
-Executes an arbitrary command. Just like the backticks. Let's say you want to remove the `README.rdoc` file:
-```ruby
-run "rm README.rdoc"
-```
-### rake(command, options = {})
-Runs the supplied rake tasks in the Rails application. Let's say you want to migrate the database:
-```ruby
-rake "db:migrate"
-```
-You can also run rake tasks with a different Rails environment:
-```ruby
-rake "db:migrate", env: 'production'
-```
-### route(routing_code)
-Adds a routing entry to the `config/routes.rb` file. In the steps above, we generated a person scaffold and also removed `README.rdoc`. Now, to make `PeopleController#index` the default page for the application:
-```ruby
-route "root to: 'person#index'"
-```
-### inside(dir)
-Enables you to run a command from the given directory. For example, if you have a copy of edge rails that you wish to symlink from your new apps, you can do this:
-```ruby
-inside('vendor') do
-  run "ln -s ~/commit-rails/rails rails"
-end
-```
-### ask(question)
-`ask()` gives you a chance to get some feedback from the user and use it in your templates. Let's say you want your user to name the new shiny library you're adding:
-```ruby
-lib_name = ask("What do you want to call the shiny library ?")
-lib_name << ".rb" unless lib_name.index(".rb")
-lib lib_name, <<-CODE
-  class Shiny
-  end
-CODE
-```
-### yes?(question) or no?(question)
-These methods let you ask questions from templates and decide the flow based on the user's answer. Let's say you want to freeze rails only if the user wants to:
-```ruby
-rake("rails:freeze:gems") if yes?("Freeze rails gems?")
-# no?(question) acts just the opposite.
-```
-### git(:command)
-Rails templates let you run any git command:
-```ruby
-git :init
-git add: "."
-git commit: "-a -m 'Initial commit'"
-```
-Advanced Usage
---------------
-The application template is evaluated in the context of a
-`Rails::Generators::AppGenerator` instance. It uses the `apply` action
-provided by
-[Thor](https://github.com/erikhuda/thor/blob/master/lib/thor/actions.rb#L207).
-This means you can extend and change the instance to match your needs.
-For example by overwriting the `source_paths` method to contain the
-location of your template. Now methods like `copy_file` will accept
-relative paths to your template's location.
-```ruby
-def source_paths
-  [File.expand_path(File.dirname(__FILE__))]
-end
-```

data/guides/source/rails_on_rack.md DELETED Viewed

@@ -1,333 +0,0 @@
-Rails on Rack
-=============
-This guide covers Rails integration with Rack and interfacing with other Rack components.
-After reading this guide, you will know:
-* How to use Rack Middlewares in your Rails applications.
-* Action Pack's internal Middleware stack.
-* How to define a custom Middleware stack.
---------------------------------------------------------------------------------
-WARNING: This guide assumes a working knowledge of Rack protocol and Rack concepts such as middlewares, url maps and `Rack::Builder`.
-Introduction to Rack
---------------------
-Rack provides a minimal, modular and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks, and software in between (the so-called middleware) into a single method call.
-- [Rack API Documentation](http://rack.rubyforge.org/doc/)
-Explaining Rack is not really in the scope of this guide. In case you are not familiar with Rack's basics, you should check out the [Resources](#resources) section below.
-Rails on Rack
--------------
-### Rails Application's Rack Object
-`ApplicationName::Application` is the primary Rack application object of a Rails
-application. Any Rack compliant web server should be using
-`ApplicationName::Application` object to serve a Rails
-application. `Rails.application` refers to the same application object.
-### `rails server`
-`rails server` does the basic job of creating a `Rack::Server` object and starting the webserver.
-Here's how `rails server` creates an instance of `Rack::Server`
-```ruby
-Rails::Server.new.tap do |server|
-  require APP_PATH
-  Dir.chdir(Rails.application.root)
-  server.start
-end
-```
-The `Rails::Server` inherits from `Rack::Server` and calls the `Rack::Server#start` method this way:
-```ruby
-class Server < ::Rack::Server
-  def start
-    ...
-    super
-  end
-end
-```
-Here's how it loads the middlewares:
-```ruby
-def middleware
-  middlewares = []
-  middlewares << [Rails::Rack::Debugger] if options[:debugger]
-  middlewares << [::Rack::ContentLength]
-  Hash.new(middlewares)
-end
-```
-`Rails::Rack::Debugger` is primarily useful only in the development environment. The following table explains the usage of the loaded middlewares:
-| Middleware              | Purpose                                                                           |
-| ----------------------- | --------------------------------------------------------------------------------- |
-| `Rails::Rack::Debugger` | Starts Debugger                                                                   |
-| `Rack::ContentLength`   | Counts the number of bytes in the response and set the HTTP Content-Length header |
-### `rackup`
-To use `rackup` instead of Rails' `rails server`, you can put the following inside `config.ru` of your Rails application's root directory:
-```ruby
-# Rails.root/config.ru
-require ::File.expand_path('../config/environment', __FILE__)
-use Rails::Rack::Debugger
-use Rack::ContentLength
-run Rails.application
-```
-And start the server:
-```bash
-$ rackup config.ru
-```
-To find out more about different `rackup` options:
-```bash
-$ rackup --help
-```
-Action Dispatcher Middleware Stack
-----------------------------------
-Many of Action Dispatcher's internal components are implemented as Rack middlewares. `Rails::Application` uses `ActionDispatch::MiddlewareStack` to combine various internal and external middlewares to form a complete Rails Rack application.
-NOTE: `ActionDispatch::MiddlewareStack` is Rails equivalent of `Rack::Builder`, but built for better flexibility and more features to meet Rails' requirements.
-### Inspecting Middleware Stack
-Rails has a handy rake task for inspecting the middleware stack in use:
-```bash
-$ bin/rake middleware
-```
-For a freshly generated Rails application, this might produce something like:
-```ruby
-use Rack::Sendfile
-use ActionDispatch::Static
-use Rack::Lock
-use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x000000029a0838>
-use Rack::Runtime
-use Rack::MethodOverride
-use ActionDispatch::RequestId
-use Rails::Rack::Logger
-use ActionDispatch::ShowExceptions
-use ActionDispatch::DebugExceptions
-use ActionDispatch::RemoteIp
-use ActionDispatch::Reloader
-use ActionDispatch::Callbacks
-use ActiveRecord::Migration::CheckPending
-use ActiveRecord::ConnectionAdapters::ConnectionManagement
-use ActiveRecord::QueryCache
-use ActionDispatch::Cookies
-use ActionDispatch::Session::CookieStore
-use ActionDispatch::Flash
-use ActionDispatch::ParamsParser
-use Rack::Head
-use Rack::ConditionalGet
-use Rack::ETag
-run MyApp::Application.routes
-```
-The default middlewares shown here (and some others) are each summarized in the [Internal Middlewares](#internal-middleware-stack) section, below.
-### Configuring Middleware Stack
-Rails provides a simple configuration interface `config.middleware` for adding, removing and modifying the middlewares in the middleware stack via `application.rb` or the environment specific configuration file `environments/<environment>.rb`.
-#### Adding a Middleware
-You can add a new middleware to the middleware stack using any of the following methods:
-* `config.middleware.use(new_middleware, args)` - Adds the new middleware at the bottom of the middleware stack.
-* `config.middleware.insert_before(existing_middleware, new_middleware, args)` - Adds the new middleware before the specified existing middleware in the middleware stack.
-* `config.middleware.insert_after(existing_middleware, new_middleware, args)` - Adds the new middleware after the specified existing middleware in the middleware stack.
-```ruby
-# config/application.rb
-# Push Rack::BounceFavicon at the bottom
-config.middleware.use Rack::BounceFavicon
-# Add Lifo::Cache after ActiveRecord::QueryCache.
-# Pass { page_cache: false } argument to Lifo::Cache.
-config.middleware.insert_after ActiveRecord::QueryCache, Lifo::Cache, page_cache: false
-```
-#### Swapping a Middleware
-You can swap an existing middleware in the middleware stack using `config.middleware.swap`.
-```ruby
-# config/application.rb
-# Replace ActionDispatch::ShowExceptions with Lifo::ShowExceptions
-config.middleware.swap ActionDispatch::ShowExceptions, Lifo::ShowExceptions
-```
-#### Deleting a Middleware
-Add the following lines to your application configuration:
-```ruby
-# config/application.rb
-config.middleware.delete "Rack::Lock"
-```
-And now if you inspect the middleware stack, you'll find that `Rack::Lock` is
-not a part of it.
-```bash
-$ bin/rake middleware
-(in /Users/lifo/Rails/blog)
-use ActionDispatch::Static
-use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00000001c304c8>
-use Rack::Runtime
-...
-run Blog::Application.routes
-```
-If you want to remove session related middleware, do the following:
-```ruby
-# config/application.rb
-config.middleware.delete "ActionDispatch::Cookies"
-config.middleware.delete "ActionDispatch::Session::CookieStore"
-config.middleware.delete "ActionDispatch::Flash"
-```
-And to remove browser related middleware,
-```ruby
-# config/application.rb
-config.middleware.delete "Rack::MethodOverride"
-```
-### Internal Middleware Stack
-Much of Action Controller's functionality is implemented as Middlewares. The following list explains the purpose of each of them:
-**`Rack::Sendfile`**
-* Sets server specific X-Sendfile header. Configure this via `config.action_dispatch.x_sendfile_header` option.
-**`ActionDispatch::Static`**
-* Used to serve static assets. Disabled if `config.serve_static_assets` is `false`.
-**`Rack::Lock`**
-* Sets `env["rack.multithread"]` flag to `false` and wraps the application within a Mutex.
-**`ActiveSupport::Cache::Strategy::LocalCache::Middleware`**
-* Used for memory caching. This cache is not thread safe.
-**`Rack::Runtime`**
-* Sets an X-Runtime header, containing the time (in seconds) taken to execute the request.
-**`Rack::MethodOverride`**
-* Allows the method to be overridden if `params[:_method]` is set. This is the middleware which supports the PUT and DELETE HTTP method types.
-**`ActionDispatch::RequestId`**
-* Makes a unique `X-Request-Id` header available to the response and enables the `ActionDispatch::Request#uuid` method.
-**`Rails::Rack::Logger`**
-* Notifies the logs that the request has began. After request is complete, flushes all the logs.
-**`ActionDispatch::ShowExceptions`**
-* Rescues any exception returned by the application and calls an exceptions app that will wrap it in a format for the end user.
-**`ActionDispatch::DebugExceptions`**
-* Responsible for logging exceptions and showing a debugging page in case the request is local.
-**`ActionDispatch::RemoteIp`**
-* Checks for IP spoofing attacks.
-**`ActionDispatch::Reloader`**
-* Provides prepare and cleanup callbacks, intended to assist with code reloading during development.
-**`ActionDispatch::Callbacks`**
-* Runs the prepare callbacks before serving the request.
-**`ActiveRecord::Migration::CheckPending`**
-* Checks pending migrations and raises `ActiveRecord::PendingMigrationError` if any migrations are pending.
-**`ActiveRecord::ConnectionAdapters::ConnectionManagement`**
-* Cleans active connections after each request, unless the `rack.test` key in the request environment is set to `true`.
-**`ActiveRecord::QueryCache`**
-* Enables the Active Record query cache.
-**`ActionDispatch::Cookies`**
-* Sets cookies for the request.
-**`ActionDispatch::Session::CookieStore`**
-* Responsible for storing the session in cookies.
-**`ActionDispatch::Flash`**
-* Sets up the flash keys. Only available if `config.action_controller.session_store` is set to a value.
-**`ActionDispatch::ParamsParser`**
-* Parses out parameters from the request into `params`.
-**`ActionDispatch::Head`**
-* Converts HEAD requests to `GET` requests and serves them as so.
-**`Rack::ConditionalGet`**
-* Adds support for "Conditional `GET`" so that server responds with nothing if page wasn't changed.
-**`Rack::ETag`**
-* Adds ETag header on all String bodies. ETags are used to validate cache.
-TIP: It's possible to use any of the above middlewares in your custom Rack stack.
-Resources
----------
-### Learning Rack
-* [Official Rack Website](http://rack.github.io)
-* [Introducing Rack](http://chneukirchen.org/blog/archive/2007/02/introducing-rack.html)
-* [Ruby on Rack #1 - Hello Rack!](http://m.onkey.org/ruby-on-rack-1-hello-rack)
-* [Ruby on Rack #2 - The Builder](http://m.onkey.org/ruby-on-rack-2-the-builder)
-### Understanding Middlewares
-* [Railscast on Rack Middlewares](http://railscasts.com/episodes/151-rack-middleware)