9.1 Updating Users

The pattern for editing user information closely parallels that for
creating new users (Chapter 7). Instead of a new action rendering a view
for new users, we have an edit action rendering a view to edit users;
instead of create responding to a POST request, we have an update action
responding to a PATCH request (Box 3.3). The biggest difference is that,
while anyone can sign up, only the current user should be able to update
their information. This means that we need to enforce access control so
that only authorized users can edit and update; the authentication
machinery from Chapter 8 will allow us to use a before filter to ensure
that this is the case.
9.2.3 Friendly Forwarding

Our site authorization is complete as written, but there is one minor
blemish: when users try to access a protected page, they are currently
redirected to their profile pages regardless of where they were trying
to go. In other words, if a non-logged-in user tries to visit the edit
page, after signing in the user will be redirected to /users/1 instead
of /users/1/edit. It would be much friendlier to redirect them to their
intended destination instead.

To test for such “friendly forwarding”, we first visit the user edit
page, which redirects to the signin page. We then enter valid signin
information and click the “Sign in” button. The resulting page, which by
default is the user’s profile, should in this case be the “Edit user”
page. The test for this sequence appears in Listing 9.16.
9.3 Showing all Users

In this section, we’ll add the penultimate user action, the index
action, which is designed to display all the users instead of just one.
Along the way, we’ll learn about populating the database with sample
users and paginating the user output so that the index page can scale up
to display a potentially large number of users. A mockup of the
result—users, pagination links, and a “Users” navigation link—appears in
Figure 9.7.6 In Section 9.4, we’ll add an administrative interface to
the user index so that (presumably troublesome) users can be destroyed.
9.3.2 Sample Users

In this section, we’ll give our lonely sample user some company. Of
course, to create enough users to make a decent user index, we could use
our web browser to visit the signup page and make the new users one by
one, but far a better solution is to use Ruby (and Rake) to make the
users for us.
9.3.3 Pagination

Our original user doesn’t suffer from loneliness any more, but now we
have the opposite problem: our user has too many companions, and they
all appear on the same page. Right now there are a hundred, which is
already a reasonably large number, and on a real site it could be
thousands. The solution is to paginate the users, so that (for example)
only 30 show up on a page at any one time.

There are several pagination methods in Rails; we’ll use one of the
simplest and most robust, called will_paginate. To use it, we need to
include both the will_paginate gem and bootstrap-will_paginate, which
configures will_paginate to use Bootstrap’s pagination styles.
9.3.4 Partial refactoring

The paginated user index is now complete, but there’s one improvement I
can’t resist including: Rails has some incredibly slick tools for making
compact views, and in this section we’ll refactor the index page to use
them. Because our code is well-tested, we can refactor with confidence,
assured that we are unlikely to break our site’s functionality.