rails

History

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
..
lib	Fix handling SCRIPT_NAME from within mounted engine's	2012-08-11 00:21:46 +02:00
test	Fix handling SCRIPT_NAME from within mounted engine's	2012-08-11 00:21:46 +02:00
actionpack.gemspec	Fix build. Bump Journey requirements to 2.0.0.	2012-07-24 02:25:38 +09:00
CHANGELOG.md	Add 'X-Frame-Options' => 'SAMEORIGIN' and 'X-XSS-Protection' => '1; mode=block' CHANGELOG entry	2012-08-10 13:19:09 -03:00
MIT-LICENSE	Updated copyright notices for 2012	2011-12-31 20:30:08 +00:00
Rakefile	Add test directory to TestTask's libs	2012-05-11 19:25:19 -03:00
README.rdoc	Remove outdated examples and feature highlights	2012-08-07 18:11:42 -05:00
RUNNING_UNIT_TESTS	ActiveRecord is no more in controller directory.	2011-10-29 12:34:08 +05:30

README.rdoc

= Action Pack -- From request to response

Action Pack is a framework for handling and responding to web requests. It
provides mechanisms for *routing* (mapping request URLs to actions), defining
*controllers* that implement actions, and generating responses by rendering
*views*, which are templates of various formats. In short, Action Pack
provides the view and controller layers in the MVC paradigm.

It consists of several modules:

* Action Dispatch, which parses information about the web request, handles
routing as defined by the user, and does advanced processing related to HTTP
such as MIME-type negotiation, decoding parameters in POST/PUT bodies,
handling HTTP caching logic, cookies and sessions.

* Action Controller, which provides a base controller class that can be
subclassed to implement filters and actions to handle requests. The result
of an action is typically content generated from views.

* Action View, which handles view template lookup and rendering, and provides
view helpers that assist when building HTML forms, Atom feeds and more.
Template formats that Action View handles are ERB (embedded Ruby, typically
used to inline short Ruby snippets inside HTML), and XML Builder.

With the Ruby on Rails framework, users only directly interface with the
Action Controller module. Necessary Action Dispatch functionality is activated
by default and Action View rendering is implicitly triggered by Action
Controller. However, these modules are designed to function on their own and
can be used outside of Rails.

== Download and installation

The latest version of Action Pack can be installed with RubyGems:

% [sudo] gem install actionpack

Source code can be downloaded as part of the Rails project on GitHub

* https://github.com/rails/rails/tree/master/actionpack

== License

Action Pack is released under the MIT license:

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

== Support

API documentation is at

* http://api.rubyonrails.org

Bug reports and feature requests can be filed with the rest for the Ruby on Rails project here:

* https://github.com/rails/rails/issues