| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
config.generators.test_framework 'rspec' for instance
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
MockLogger for LogSubscriber.
|
|
|
|
| |
starts avoiding reference loops.
|
| |
|
|
|
|
| |
initialization syntax
|
|
|
|
| |
javascript_expansions[:defaults]
|
|
|
|
| |
environment.
|
| |
|
| |
|
|
|
|
| |
Your application should *always* reference your application const (as Blog::Application) and Rails.application should be used just internally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
notices, and make the behaviors independent of the environment names.
* In Rails 2.3 apps being upgraded, you will need to add the deprecation
configuration to each of your environments. Failing to do so will
result in the same behavior as Rails 2.3, but with an outputted warning
to provide information on how to set up the setting.
* New Rails 3 applications generate the setting
* The notification style will send deprecation notices using
ActiveSupport::Notifications. Third-party tools can listen in to
these notifications to provide a streamlined view of the
deprecation notices occurring in your app.
* The payload in the notification is the deprecation warning itself
as well as the callstack from the point that triggered the
notification.
|
| |
|
|
|
|
|
|
| |
* 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;
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
|
| |
It turned out to be that scaffold for singeleton resource will always depend on another model, and it's not possible at the moment to make the application tests pass after generate the singeleton scafold. So, it would be better to remove it for now and probably provide another generator, such as singeleton_scaffold, in which also require the depended model name.
[#4863 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
ActiveSupport::LogSubscriber in [6788db824ab732b13493a9d702dd8fb89fa153c8] [#4816 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
Doesn't make up for the fact that it's slooooooooow, though.
Signed-off-by: wycats <wycats@gmail.com>
|
|
|
|
| |
frameworks like ActiveRecord and ActiveResource to log outsude Rails::Application [#4816 state:resolved]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
[#2244 state:open]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
| |
This patch is not consistent since it leaves similar
directories in load_paths, needs more thought.
This reverts commit b5fe014fdcc285f3bcb8779c4f7cfbc5a820856f.
|
|
|
|
|
|
|
|
|
|
|
| |
Conceptually, the lib directory is closer 3rd party libraries
than to the application itself. Thus, Rails adds it to Ruby's
load path ($LOAD_PATH, $:) but it is no longer included in
dependencies' load paths.
To enable autoloading back put this in your config/application.rb
config.load_paths += %W( #{config.root}/lib )
|
| |
|
|
|
|
|
|
| |
[#4835 state:committed]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
|
|
|
| |
not "ActiveRecord"
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
|
|
|
| |
thanks to Marc-Andre Lafortune
|
|
|
|
| |
earlier. Also tidy up the guide a little bit.
|
|
|
|
| |
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.
|
|
|
|
| |
backend if it was set through config.i18n.backend.
|