Reputation: 250
Is it proper to have a static_pages
controller whose only purpose is to render static pages in large apps? Take the following scenario for instance:
You are developing a social network application and are devising the design of the application. You know you will need to be able to route some pages, like:
My question is: would you define a static_pages
controller to handle the landing page and, later, when an authentication system is in place, check to see if [a user is] authenticated and replace templates? Or might you go without such a controller, opting to create a users_controller
with a :before_action
that checks for authentication, and redirects (on failure (read: unauthenticated users)) to the aforementioned landing page?
According to the Rails tutorial by Michael Hartl, the static_pages
controller would be the way to go; however, my thinking is that that tutorial is geared at very new users of the framework and, perhaps, thus doesn't use the best of conventions in the name of simplicity.
What would be the preferred way, mainly in something of a large app (like Twitter, for example, or even StackOverflow), to handle such a situation?
Upvotes: 2
Views: 155
Reputation: 1895
Yeah it doesn't really make any sense to have a static controller, unless you have something major happening on those pages, that is specific to those pages. In the end it all comes down to your personal preference in how you feel comfortable structuring your app, but in a professional environment, and in the case of Twitter or StackOverflow, they almost certainly wouldn't have static controllers. You're right in assuming that Hartl's guide is geared toward beginners and is meant to teach the basics, not the finer points and conventions. If you need to authenticate a user on a static page, Rails convention absolutely dictates that you would perform that authentication in a users_controller
.
Upvotes: 1