| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
|
| |
Now you can start your apps with jquery with rails new myapp -j jquery, the default is still prototype
[#5613 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
|
|
|
| |
This change caused by confusion caused by calling engine
"namespaced". Stuff inside engine can be namespaced for every
engine. This method is not actually namespacing anything, it's
isolating engine within the given namespace.
|
| |
|
|
|
|
|
|
| |
[#4104 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
|
|
| |
used
[#4104]
|
|
|
|
|
|
|
| |
The phrase "clean up" misrepresents the fact that this removes
a feature that ships with Rails 3.0.
This reverts commit 6774e12afa0f29442aa612ddf6e51d5a1b7a4356.
|
|
|
|
| |
This commit may be reverted once documentation and a proper way to handle actions are added.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Normally Rails.application is an instance, but for those
tests Rails.application needs to be class.
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>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
namespaced model
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
warnings in the scaffold_generator tests [#4872 state:resolved]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
[#5526 state:committed]
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>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
corresponding test suites to be cleaner. [#5434 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
[#5435 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
| |
|
|
|
|
|
|
|
|
| |
current app name whenever possible. This means that renaming the residing directory will not effect the app name generated by AppGenerator.
[#5225 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
used. [#5263 state:open]
|
|
|
|
|
|
| |
[#5245 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
|
|
|
|
| |
--skip-test-unit and --skip-active-record respectively
Reason is their proper spellings are "Test::Unit" and "Active Record".
Option names and descriptions have been revised, as well as some method
names and minor details here and there.
|
|
|
|
| |
initialization syntax
|
|
|
|
| |
javascript_expansions[:defaults]
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
[#4835 state:committed]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
earlier. Also tidy up the guide a little bit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|