Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Default Index Page Dynamic #7771

Closed
wants to merge 1 commit into from

Conversation

schneems
Copy link
Member

Rails is a dynamic framework that serves a static index.html by default. One of my first questions ever on IRC was solved by "delete your index.html". 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 and show people how to set the root on their project all at the same time.

I encounter this question any time I am helping someone new learn Rails, and it is advice repeated again and again from our comments in rails/rails to external tutorials. We can remove this extra step and show people how to use rails root in the routes by allowing the index to be dynamic.

In addition to helping new programmers, this will help Rails engine gem's that need to redirect to a url. Many of them would like to use root_url such as devise, but cannot count on it being there. This change adds in a default page for the root to avoid this issue and to standardize on a place for custom landing pages for applications. If no custom landing page is desired one can easily remove the route, controller, and view. Alternatively they could change the root in routes and leave the other files if they might want a custom landing page eventually.

Screenshot:

schneems added a commit to schneems/rails that referenced this pull request Sep 27, 2012
Dynamic error pages have many benefits over static, for instance they can use the default layout if desired. By generating dynamic error pages by default we can encourage developers to take advantage of this already existing feature and build better sites. In addition to moving people towards dynamically generating their error pages we can add prompts to the default pages. One example is telling devs how to get to their logs. I have added erb to `errors/500.html.erb` that I believe will be extremely helpful to new developers.

While walking users through a deployment (such as with http://railsgirls.com/materials) they often are not familiar with how to retrieve logs on a given system. I've added a dynamic section that will look for an environment variable `CHECK_LOG_INSTRUCTIONS` and if present show a corresponding message. I can then work with @hone to get a debug log message into the [ruby buildpack](https://github.com/heroku/heroku-buildpack-ruby) something like `$ heroku logs --tail`. While we've added a number of great error messages to Rails, helping developers find those error messages is crucial to their sustained success. This isn't just for new devs either. Experienced Rails developers who are new to a system might not know how to access its logs.

By relying on an ENV var we're not coupling the message to any one provider, and if no message is present we fall back on the default error page. It would be the responsibility of providers to set this message on a given system.

Moving in this direction we should also port over `public/index.html` to a dynamic page. This change can be found in a separate PR with it's own set of benefits rails#7771

Screenshot when running production with `CHECK_LOG_INSTRUCTIONS` set:

![](http://f.cl.ly/items/2E2J3u2b1d2S3s3Y3l1V/Screen%20Shot%202012-09-27%20at%2011.00.16%20AM.png)
* Remove highly uncommon `config.assets.manifest` option for moving the manifest path.
This option is now unsupported in sprockets-rails.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably shouldn't mess with other CHANGELOG lines.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change is fine. I hate these whitespaces

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, sorry :trollface:

@steveklabnik
Copy link
Member

This is a big change, but I am 👍.

@subdigital
Copy link
Contributor

👍

@maxim
Copy link
Contributor

maxim commented Sep 27, 2012

It does teach the way public/ works early on. Although perhaps simply following the advice "delete your index.html" doesn't actually teach anything.

# root to: 'welcome#index'
root to: 'pages#index'

resources :pages

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add :only => :show? Since there are no other actions on that controller?

@ryanb
Copy link
Contributor

ryanb commented Sep 27, 2012

My concern is the number of steps it takes to get to a blank project. Now instead of just removing one file, I need to remove a controller, view directory, and the routes?

What if we generate no additional files, and simply have one line in the routes file:

root to: welcome_aboard

This could be a rack handler which responds with the dynamic content internally (like the existing /rails/info/properties path works).

@josevalim
Copy link
Contributor

I agree with @ryanb on this one. This is adding a lot of noise for people that actually want to build a new application and get stuff of the way in order to make it easier for people just starting. Both audiences matter but in this case the amount of noise added is not worth it.

@schneems
Copy link
Member Author

@ryanb abstracing this away from the user even further would be the oposite intention of this PR. Why not use Rails features to build rails? @josevalim we can modify the --without-index flag to not produce these files. Not having a default root is a sore spot in the rails new process for me. It even has to be documented in plataformatec/devise and other gems expecting a root. It is unexpected and very uncommon to have a website that does not have a homepage. Would like to standardize this for new rails installs. I've never seen a production project with out a welcome/hello/pages/ohai controller that served a homepage.

@ryanb
Copy link
Contributor

ryanb commented Sep 27, 2012

@schneems I'm okay with it if it is intended to be a standardized way to have a home page. In that case I suggest renaming it to WelcomeController and removing the show action so there's no need for the resources route. Naming it Pages interferes with a dynamic Page resource which is common in CMS type apps.

I like the idea of a root route by default. This would allow gems to use root_url reliably.

@schneems
Copy link
Member Author

@ryanb I chose pages because it can be pluralized with no problems (welcomes?) and is agnostic in meaning. It also played nice with this sister pull request #7772 and could give a default place for about/privacy/etc. (as opposed to welcomes/about, homes/privacy).

1.9.3dev :001 > "welcome".pluralize
 => "welcomes" 
1.9.3dev :002 > "home".pluralize
 => "homes" 
1.9.3dev :003 > "page".pluralize
 => "pages" 

At the end of the day i'm impartial to the naming as long as we get rid of public/index.html :) We can also kill the show action if desired, thought it would be nice to show potential implementation, instead of making a separate controller for "static-ish" pages.

@ryanb
Copy link
Contributor

ryanb commented Sep 27, 2012

@schneems Does the controller need to be plural? If it is just displaying the home page I don't see why.

Pages does make sense if you are using it to handle other pages (about/privacy as you mentioned). In that case how about using this route instead of resources :pages

get 'pages/:page', to: 'pages#show', as: 'page'

If this is intended to be an educational example I don't think resources is a good fit since it produces many more routes. Even with only: :show it doesn't feel right.

I still think this is too complex overall for the default app generator.

@tyre
Copy link

tyre commented Sep 27, 2012

@ryanb @schneems Why not just have the file be called welcome.html and redirect root there? The most confusing part of index.html is its name because it then overrides every index until you figure out how to delete it. Post-asset pipeline, the role of public/ is greatly diminished so don't send new users through a loop to delete unnecessary files.

@jdxcode
Copy link

jdxcode commented Sep 27, 2012

+1 for this I've probably made 100 new rails apps and still forget to do this

also, I think rails should set a convention for what a 'home' or 'root' controller/action should be

@schneems
Copy link
Member Author

Convention is: models are singular, controllers are plural, and therefore view folders are pluralized. Generating files that goes against that convention seems bad for a convention-over-configuration advocacy standpoint. A controller-view-route is the minimum required to deliver a generated webpage (with a template) using Rails.

We can remove the resources :pages in the routes along with the show action, it is noise in this PR. I will do it as soon as I get a chance.

@schneems
Copy link
Member Author

Updated routes, removed show action and associated routes from PagesController.

class PagesController < ApplicationController

def index
render :layout => false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, use 1.9 hash syntax here. Thanks.

@steveklabnik
Copy link
Member

@schneems , are you still working on this?

Rails is a dynamic framework that serves a static `index.html` by default. One of my first questions ever on IRC was solved by "delete your index.html". 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 and show people how to set the root on their project all at the same time.

I encounter this question any time I am helping someone new learn Rails, and it is advice repeated again and again from our comments in rails/rails to external tutorials. We can remove this extra step and show people how to use rails root in the routes by allowing the index to be dynamic. 

This makes it easier to understand how to replace the root if desired, or to modify the index once generated since all rails helper methods are available. Eventually we can refactor this page to use standard Rails helpers instead of pure static html.

Screenshot:

![](http://f.cl.ly/items/38212K0w1P063u2I0g2E/Screen%20Shot%202012-09-25%20at%204.51.42%20PM.png)
@schneems
Copy link
Member Author

I updated the hash to 1.9 syntax, rebased out the trailing whitespace removal. I would like to open up the discussion on this PR again.

I still believe we should use Rails features to deliver this home page out of the box. A question to those who might oppose this change: If we already had a rails controller and view rendering the default index page what benefits would we gain by moving to a static home page instead? Does the static page provide functionality above and beyond a dynamically rendered home/welcome page?

@wsouto
Copy link

wsouto commented Nov 28, 2012

💯 on this.

@spastorino
Copy link
Contributor

Just wanted to comment that we already had this discussion but I never coded it. @schneems check 5c1109a#commitcomment-1307473 and please do it :)

schneems added a commit to schneems/rails that referenced this pull request Dec 11, 2012
This is an alternative implementation to rails#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 rails#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.
@schneems
Copy link
Member Author

closing in favor of #8468

@schneems schneems closed this Dec 11, 2012
schneems added a commit to schneems/rails that referenced this pull request Sep 28, 2014
This is an alternative implementation to rails#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 rails#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet