| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
configuration in request.env. This is another step forward removing global configuration.
|
|
|
|
| |
deep nesting works in controllers.
|
|
|
|
| |
ActionController::Base.session_store= in favor of a config.session_store method (which takes params) and a config.cookie_secret variable, which is used in various secret scenarios. The old AC::Base options will continue to work with deprecation warnings.
|
| |
|
|
|
|
| |
lookup.
|
|
|
|
| |
Signed-off-by: Carl Lerche <carllerche@mac.com>
|
|
|
|
| |
paths, load active_support/railtie since we need it and ensure default logger is set before config.
|
| |
|
| |
|
| |
|
| |
|
|
children.
|