| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
method_missing.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from railties.
With config.generators becomes a way to configure generators
for current instance only. For example:
module Blog
class Engine < Rails::Engine
config.generators do |g|
g.orm :active_record
end
config.app_generators do |g|
g.test_framework :rspec
end
end
end
such definition sets :active_record as orm for engine and :rspec
as test_framework for application. The values set with app_generators
can be overwritten in application using config.generators as you would
normally do:
module MyApp
class Application < Rails::Application
config.generators do |g|
g.test_framework :test_unit
end
end
end
|
| |
|
| |
|
|
|
|
| |
ActionDispatch::Static in initializers
|
| |
|
|
|
|
| |
Application::Configurable in favor of unified Railtie::Configurable
|
| |
|
| |
|
|
|
|
| |
method between Engine and Application
|
| |
|
|
|
|
| |
looping through initializers
|
| |
|
| |
|
|
|
|
| |
ensuring all configuration options were applied.
|
| |
|
|
|
|
|
|
| |
* Added :autoload to engines path API and redefine usage to be in sync with 6f83a5036d8a9c3f8ed7;
* Do not autoload code in *lib* for applications (now you need to explicitly require them). This makes an application behave closer to an engine (code in lib is still autoloaded for plugins);
* Always autoload code in app/ for engines and plugins. This makes engines behave closer to an application and should allow us to get rid of the unloadable hack required when controllers inside engines inherit from ApplicationController;
|
|
|
|
| |
frameworks like ActiveRecord and ActiveResource to log outsude Rails::Application [#4816 state:resolved]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
code during configuration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
middleware stack via config.middleware.use. You can use
methods on the middleware stack to control exactly where
it should go
* if it behaves like a Rack endpoint, you can link to it
in the router. This will result in more optimal routing
time, and allows you to remove code in your endpoint
that matches specific URLs in favor of the more powerful
handling in the router itself.
For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.
Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.
|
| |
|
|
|
|
| |
This reverts commit ade756fe42423033bae8e5aea8f58782f7a6c517.
|
|
|
|
| |
This reverts commits af0d1a88157942c6e6398dbf73891cff1e152405 and 64d109e3539ad600f58536d3ecabd2f87b67fd1c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Default Encoding.default_internal to UTF-8
* Eliminated the use of file-wide magic comments to coerce code evaluated inside the file
* Read templates as BINARY, use default_external or template-wide magic comments
inside the Template to set the initial encoding
* This means that template handlers in Ruby 1.9 will receive Strings encoded
in default_internal (UTF-8 by default)
* Create a better Exception for encoding issues, and use it when the template
source has bytes that are not compatible with the specified encoding
* Allow template handlers to opt-into handling BINARY. If they do so, they
need to do some of their own manual encoding work
* Added a "Configuration Gotchas" section to the intro Rails Guide instructing
users to use UTF-8 for everything
* Use config.encoding= in Ruby 1.8, and raise if a value that is an invalid
$KCODE value is used
Also:
* Fixed a few tests that were assert() rather than assert_equal() and
were caught by Minitest requiring a String for the message
* Fixed a test where an assert_select was misformed, also caught by
Minitest being more restrictive
* Fixed a test where a Rack response was returning a String rather
than an Enumerable
|
| |
|
|
|
|
| |
from plugin developers.
|
|
|
|
|
|
| |
is built by using another pattern.
Also create a engine_blank_point initializer to ensure any :before or :after hooks defined inside engines won't move the configuration initializers to other places.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without the need for Railtie. Specifically, the following hooks were added:
* before_configuration: this hook is run immediately after the Application class
comes into existence, but before the user has added any configuration. This is
the appropriate place to set configuration for your plugin
* before_initialize: This is run after all of the user's configuration has completed,
but before any initializers have begun (in other words, it runs right after
config/environments/{development,production,test}.rb)
* after_initialize: This is run after all of the initializers have run. It is an
appropriate place for forking in a preforking setup
Each of these hooks may be used via ActiveSupport.on_load(name) { }. In all these cases, the context inside the block will be the Application object. This means that for simple cases, you can use these hooks without needing to create a Railtie.
|
| |
|
|
|
|
| |
state:resolved].
|
|
|
|
| |
initializing the application on its own. This fixes [#4492 state:resolved] and also avoids the application being initialized twice in some rake tasks.
|
|
|
|
| |
delegates to the config object, reducing the number of deprecations and add specific tests.
|
|
|
|
| |
significant places.
|
|
|
|
| |
started in another directory which is not the RAILS_ROOT.
|
| |
|
|
|
|
| |
configuration in request.env. This is another step forward removing global configuration.
|
|
|
|
|
|
| |
[#4315 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
|
| |
should run during framework load do:
ActiveSupport.on_load(:action_controller) do
# Code run in the context of AC::Base
end
|
|
|
|
| |
remove railtie_name and engine_name and allow to set the configuration object.
|
| |
|
|
|
|
| |
middleware, either use Rails.application.config.middleware or modify it in an initializer (if you need to set it relative to user-specified middleware).
|
|
|
|
|
|
|
|
|
|
|
|
| |
add lazy_load_hooks.rb, which allows us to declare code that
should be run at some later time. For instance, this allows
us to defer requiring ActiveRecord::Base at boot time purely
to apply configuration. Instead, we register a hook that should
apply configuration once ActiveRecord::Base is loaded.
With these changes, brings down total boot time of a
new app to 300ms in production and 400ms in dev.
TODO: rename base_hook
|
|
|
|
| |
doesn't subscribe to *every* event, so we can have events that are slow-ish but are not actually run in production.
|