| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This PR adds formatting and meta-data to the display of the internal routes. Users can now toggle between showing helpers with the `_path` or _`url` suffix.
There are multiple ways to achieve this, this method uses partials for formatting and meta-data. The partials can be re-used when rendering `routing_error.erb`, though that will need to be in a separate PR.
ATP Railties
|
| |/
|
|
| |
directory structure and load path
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an alternative implementation to #7771 thanks to the advice of @spastorino
Rails is a dynamic framework that serves a static index.html by default. One of my first questions ever on IRC was solved by simply deleting my public/index.html file. This file is a source of confusion when starting as it over-rides any set "root" in the routes yet it itself is not listed in the routes. By making the page dynamic by default we can eliminate this confusion.
This PR moves the static index page to an internal controller/route/view similar to `rails/info`. When someone starts a rails server, if no root is defined, this route will take over and the "dynamic" index page from rails/welcome_controller will be rendered. These routes are only added in development. If a developer defines a root in their routes, it automatically takes precedence over this route and will be rendered, with no deleting of files required.
In addition to removing this source of confusion for new devs, we can now use Rails view helpers to build and render this page. While not the primary intent, the added value of "dogfooding" should not be under-estimated.
The prior PR #7771 had push-back since it introduced developer facing files. This PR solves all of the same problems, but does not have any new developer facing files (it actually removes one).
cc/ @wsouto, @dickeyxxx, @tyre, @ryanb, @josevalim, @maxim, @subdigital, @steveklabnik
ATP Railties and Actionpack.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
If you generate a full engine, this will include rake tasks from
your gem under the `app` namespace. For example if you have a dependency
on `rspec-rails` in your engine's `gemspec`. You will get the task `app:spec`
Closes #8229
|
| | |
|
| |
|
|
| |
invocations of "rails new".
|
| | |
|
| |
|
|
|
|
|
| |
Closes #8121
The `plugin new` generator always adds the dummy app rake tasks,
when a dummy app was created.
|
| |
|
|
| |
Fixes #8025
|
| |
|
|
|
|
| |
Should not eager_load app/assets
Conflicts:
railties/CHANGELOG.md
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the default test locations to avoid confusion around the common
testing terms "unit" and "functional".
Add new rake tasks for the new locations, while maintaining backwards
compatibility with the old rake tasks.
New testing locations are as follows:
app/models -> test/models (was test/units)
app/helpers -> test/helpers (was test/units/helpers)
app/controllers -> test/controllers (was test/functional)
app/mailers -> test/mailers (was test/functional)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
manifest path.
This option is now unsupported in sprockets-rails.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users of other SCM's can now generate rails
apps that will add the "empty" directories to source control,
but will not have a useless .gitignore or mis-named .gitkeep
files.
* Change `rails new` and `rails plugin new` generators to name
the `.gitkeep` as `.keep` in a more SCM-agnostic way.
* Change `--skip-git` option to only skip the `.gitignore` file
and still generate the `.keep` files.
* Add `--skip-keeps` option to skip the `.keep` files.
It closes #2800.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- added tests to confirm establish_connection uses DATABASE_URL and
Rails.env correctly even when no arguments are passed in.
- updated rake db tasks to support DATABASE_URL, and added tests to
confirm correct behavior for these rake tasks. (Removed
establish_connection call from some tasks since in those cases
the :environment task already made sure the function would be called)
- updated Resolver so that when it resolves the database url, it
removes hash values with empty strings from the config spec (e.g.
to support connection to postgresql when no username is specified).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Changes in old branches needed to be manually synched in CHANGELOGs of newer ones.
This has proven to be brittle, sometimes one just forgets this manual step.
With this commit we switch to CHANGELOGs per branch. When a new major version is
cut from master, the CHANGELOGs in master start being blank.
A link to the CHANGELOG of the previous branch allows anyone interested to
follow the history.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.
Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.
This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.
This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:
- generating engine's route from application: in this situation
SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
indicates the place where application is mounted, so we can just pass
it as :original_script_name in url_options. :original_script_name is
used because if we use :script_name, router will ignore generating
prefix for engine
- generating application's route from engine: in this situation we
already lost information about the SCRIPT_NAME that server used. For
example if application is mounted at /myapp and engine is mounted at
/blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
we need to keep reference to /myapp SCRIPT_NAME by binding it to the
current router. Later on we can extract it and use when generating url
Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.
(closes #6933)
|
| |
|
|
| |
basic data". I dont consider this something most people is going to want most of the time. If you want to add it in your own app, knock yourself out. But it doesnt belong in Rails imo
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
AddXXXToYYY/RemoveXXXFromYYY migrations are produced with references
statements, for instance
rails g migration AddReferencesToProducts user:references
supplier:references{polymorphic}
will generate the migration with:
add_reference :products, :user, index: true
add_reference :products, :supplier, polymorphic: true, index: true
|
| |
|
|
|
| |
Pull request #6856, merged in 52f6e47682003c83b0466bf5e140ee302498a226.
[ci skip]
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Will show similar contents to the output of `$ rake routes` in the browser in development. This speeds the time required to generate routes, since the application is already initialized.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Dear Active Resource,
It's not that I hate you or anything, but you didn't get much attention lately. There're so many alternatives out there, and I think people have made their choice to use them than you. I think it's time for you to have a big rest, peacefully in this Git repository.
I will miss you,
@sikachu.
|
| |
|
|
| |
Also add missing entries and use the formating convention
|
| |
|
|
| |
Set "March 1, 2012" as the release date for 3.2.2, 3.1.4, 3.0.12
|
| | |
|
| |
|
|
| |
the update action of resources
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds ability to set custom console if you want to use
something other than IRB. Previously the hack that people used
was:
silence_warnings do
require 'pry'
IRB = Pry
end
which is not the best way to customize things.
|
| |
|
|
|
|
| |
It is usually useful to be able to hide a generator when running rails
generate command. Such generators might be used only to dry up
generators code and shouldn't be available to end users.
|
| | |
|
| | |
|
| | |
|
