Go to file
Piotr Sarnacki 5b3bb61f3f Fix handling SCRIPT_NAME from within mounted engine's
When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.

Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.

This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.

This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:

- generating engine's route from application: in this situation
  SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
  indicates the place where application is mounted, so we can just pass
  it as :original_script_name in url_options. :original_script_name is
  used because if we use :script_name, router will ignore generating
  prefix for engine

- generating application's route from engine: in this situation we
  already lost information about the SCRIPT_NAME that server used. For
  example if application is mounted at /myapp and engine is mounted at
  /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
  we need to keep reference to /myapp SCRIPT_NAME by binding it to the
  current router. Later on we can extract it and use when generating url

Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.

(closes #6933)
2012-08-11 00:21:46 +02:00
actionmailer Revert "Merge pull request #7202 from asanghi/perform_deliveries_in_mail" 2012-08-07 14:00:54 -03:00
actionpack Fix handling SCRIPT_NAME from within mounted engine's 2012-08-11 00:21:46 +02:00
activemodel Naming helpers should first check if passed object responds to model_name 2012-08-08 22:40:06 +02:00
activerecord DRY up handling of dependent option 2012-08-10 17:45:07 +01:00
activesupport Add html_escape note to CHANGELOG 2012-08-09 16:54:52 -07:00
ci remove duplicate build runs in travis. These extra runs were used to 2012-07-24 16:44:20 -07:00
guides defines String#indent [closes #7263] [Xavier Noria & Ace Suares] 2012-08-07 16:57:28 +02:00
railties Fix handling SCRIPT_NAME from within mounted engine's 2012-08-11 00:21:46 +02:00
tasks Remove Active Resource source files from the repository 2012-03-13 14:55:44 -04:00
tools require "rubygems" is obsolete in Ruby 1.9.3 2012-05-13 14:47:25 +02:00
.gitignore moves the guides up to the root directory 2012-03-17 08:32:49 -07:00
.travis.yml Remove ARes from the list. 2012-03-14 00:00:34 +01:00
.yardopts Let YARD document the railties gem 2010-09-09 18:24:34 -07:00
Gemfile support relations created with a table alias 2012-07-13 11:44:45 +01:00
install.rb Remove Active Resource source files from the repository 2012-03-13 14:55:44 -04:00
load_paths.rb require "rubygems" is obsolete in Ruby 1.9.3 2012-05-13 14:47:25 +02:00
RAILS_VERSION rails/master is now 4.0.0.beta and will only support Ruby 1.9.3+ 2011-12-20 09:30:37 -06:00
rails.gemspec Add license field to gemspecs, by Matt Griffin 2012-05-23 09:22:25 -07:00
Rakefile Rakefile executable attributes and shebang lines has been removed 2012-05-02 13:38:13 +03:00
README.rdoc -h also shows help options. 2012-03-19 17:53:27 +05:30
RELEASING_RAILS.rdoc fixing security email address 2012-06-12 14:34:44 -07:00
version.rb rails/master is now 4.0.0.beta and will only support Ruby 1.9.3+ 2011-12-20 09:30:37 -06:00

== Welcome to Rails

Rails is a web-application framework that includes everything needed to create
database-backed web applications according to the {Model-View-Controller (MVC)}[http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller] pattern.

Understanding the MVC pattern is key to understanding Rails. MVC divides your application
into three layers, each with a specific responsibility.

The View layer is composed of "templates" that are responsible for providing 
appropriate representations of your application's resources. Templates
can come in a variety of formats, but most view templates are \HTML with embedded Ruby
code (.erb files). 

The Model layer represents your domain model (such as Account, Product, Person, Post) 
and encapsulates the business logic that is specific to your application. In Rails, 
database-backed model classes are derived from ActiveRecord::Base. Active Record allows
you to present the data from database rows as objects and embellish these data objects 
with business logic methods. Although most Rails models are backed by a database, models 
can also be ordinary Ruby classes, or Ruby classes that implement a set of interfaces as
provided by the ActiveModel module. You can read more about Active Record in its
{README}[link:/rails/rails/blob/master/activerecord/README.rdoc].

The Controller layer is responsible for handling incoming HTTP requests and providing a 
suitable response. Usually this means returning \HTML, but Rails controllers can also
generate XML, JSON, PDFs, mobile-specific views, and more. Controllers manipulate models 
and render view templates in order to generate the appropriate HTTP response.

In Rails, the Controller and View layers are handled together by Action Pack.
These two layers are bundled in a single package due to their heavy interdependence. 
This is unlike the relationship between Active Record and Action Pack which are
independent. Each of these packages can be used independently outside of Rails. You 
can read more about Action Pack in its {README}[link:/rails/rails/blob/master/actionpack/README.rdoc].

== Getting Started

1. Install Rails at the command prompt if you haven't yet:

    gem install rails

2. At the command prompt, create a new Rails application:

    rails new myapp

   where "myapp" is the application name.

3. Change directory to +myapp+ and start the web server:

    cd myapp; rails server

   Run with <tt>--help</tt> or <tt>-h</tt> for options.

4. Go to http://localhost:3000 and you'll see:

    "Welcome aboard: You're riding Ruby on Rails!"

5. Follow the guidelines to start developing your application. You may find the following resources handy:

* The README file created within your application.
* The {Getting Started with Rails}[http://guides.rubyonrails.org/getting_started.html].
* The {Ruby on Rails Tutorial}[http://railstutorial.org/book].
* The {Ruby on Rails Guides}[http://guides.rubyonrails.org].
* The {API Documentation}[http://api.rubyonrails.org].

== Contributing

We encourage you to contribute to Ruby on Rails! Please check out the {Contributing to Rails
guide}[http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html] for guidelines about how
to proceed. {Join us}[http://contributors.rubyonrails.org]!

== Build Status {<img src="https://secure.travis-ci.org/rails/rails.png"/>}[http://travis-ci.org/rails/rails]

== Dependency Status {<img src="https://gemnasium.com/rails/rails.png?travis"/>}[https://gemnasium.com/rails/rails]

== License

Ruby on Rails is released under the MIT license:

* http://www.opensource.org/licenses/MIT