| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
to field_with_errors [#157 state:resolved]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
significant places.
|
| | |
|
| |
|
|
| |
replace with better suggestion. [#4279 state:resolved]
|
| |
|
|
| |
[#4247 state:resolved]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set config.action_controller.asset_path_template to a proc that takes one
argument - the direct, unchanged asset path - and returns a path to that asset
using the scheme that your assets require.
This is useful if you have a setup which scales by introducing new application
servers where the mtime of the asset files may not be the same as those of the
asset files on your previous servers, but it does require your web servers to
have knowledge of the asset template paths that you rewrite to so it's not
suitable for out-of-the-box use. An example of configuring asset path
generation and rewriting these paths using Apache is included in
actionpack/lib/action_view/helpers/asset_tag_helper.rb.
Signed-off-by: wycats <wycats@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
