| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
I added integration tests for generating urls in Engine and application
and tweaked Engines to fully cooparate with new router's behavior:
* Rails.application now sets ORIGINAL_SCRIPT_NAME
* Rails.application also sets its routes as env['action_dispatch.parent_routes']
* Engine implements responds_to? class method to respond to all the
instance methods, like #routes
|
|
|
|
| |
determine if it should generate prefix for mounted apps
|
|
|
|
| |
Application::Configurable in favor of unified Railtie::Configurable
|
| |
|
| |
|
|
|
|
| |
method between Engine and Application
|
| |
|
| |
|
| |
|
|
|
|
| |
looping through initializers
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* 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;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: Michael Koziarski <michael@koziarski.com>
|
|
|
|
| |
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
| |
|
|
|
|
| |
configuration in request.env. This is another step forward removing global configuration.
|
|
|
|
|
|
|
|
| |
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.
|
| |
| |
| |
| | |
:railtie, :engine and so on.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/lib/active_record/base.rb
railties/lib/rails/configuration.rb
railties/lib/rails/log_subscriber.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
deep nesting works in controllers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Works after all. Culprit was 226dfc2.
This reverts commit 6189480b1878cdadb092fdfa32ba156a91e6a0e1.
|
| |
| |
| |
| |
| |
| | |
Ruby 1.9 regression.
This reverts commit 76237f163ff7ad2a64af926030e3449c547cafa2.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
stack.
|
| |
| |
| |
| | |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
railties/README
railties/guides/source/active_support_core_extensions.textile
railties/guides/source/getting_started.textile
railties/lib/generators/rails/app/templates/README
|