| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
methods
|
|
|
|
| |
loggers instead of trying to extract them each time
|
|
|
|
|
|
|
| |
* Took out stuff that's not relevant (or useful) anymore.
* Some formatting.
* Added helpful links to get started with Rails.
* Took out Apache htaccess tutorial since we aren't teaching Apache here.
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also removed the limitation of not being able to call your new server any of
the rails commands (generate, server, dbconsole, console etc) as there is
no longer any ambiguity here.
http://rails.lighthouseapp.com/projects/8994/tickets/4665
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
| |\ |
|
| | |
| | |
| | |
| | | |
earlier. Also tidy up the guide a little bit.
|
| | | |
|
| |/
|/|
| |
| | |
Signed-off-by: Rizwan Reza <rizwanreza@gmail.com>
|
|/
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: wycats <wycats@gmail.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
|
|
|
| |
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
|
|
|
|
|
|
| |
[#4602 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
| |
generator. [#2377 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
[#4574 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
"gem" [#4534 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
to support full namespaces (not just entire groups)
|
|
|
|
|
|
| |
[#4532 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
|
|
|
| |
rarely showed the full trace. Also, increase performance considerably.
|
|
|
|
|
|
|
|
|
| |
More work still needs to be done on some of these names
(render_template.action_view and render_template!.action_view particularly)
but this allows (for example) /^sql/ to subscribe to all
the various ORMs without further modification
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|\
| |
| |
| |
| | |
Conflicts:
railties/guides/source/index.html.erb
|
| | |
|