JavaServer Pages, Second Edition

7.3 User Pages

As promised, very few changes need to be made to the pages from Chapter 5. The section, article, quiz, and navigation can all stay almost exactly the same. The few things that do need to change reflect the new use of normalized tables.

In the article page, it was formerly possible to obtain the author's name with

<c:out value="${article.authorName}"/>

But because the authorName is no longer kept in the ArticleBean but only the authorId, an additional mechanism must be used to go from the ID to the author before getting the name. Fortunately, the bean provides a means to do this, by providing an author property that holds the appropriate UserInfoBean. Getting the name is then as simple as

<c:out value="${article.author.name}"/>

Note the use of a nested property.

The remaining user pages that need to be changed are those that now need to send data to the database. These consist of the page that handles the saving of user preferences (Listing 3.18) and the page that adds a comment to an article (Listing 5.9).

Recall that the user preferences are placed in the bean with the tag jsp:setProperty, just as the one used to set the article properties. Therefore, all that is needed to write these values to the database is another jsp:setProperty tag that sets the save property. This will tell the bean to save its contents to the database, and because it will already have a userInfoId from the time when the user logged in, it will know that data is being updated instead of created.

Now that the preferences for an existing user can be saved, it is easy to allow the system to create new users. First, the page should contain a message prompting users to sign up with the site. The easiest way to do this is by adding a small message to the login form in Listing 5.2:

Don't have an account yet?
Click <a href="user_preferences.jsp">here</a>
to register with Java News Today!

It may seem odd that users would be sent to the user preferences page to sign up, as that page lets existing users change their options. It would certainly be possible to create a separate sign-up page, but consider what such a page would contain. It would need a form that prompted for a user name, password, and real name, which would seem to be the minimal information needed in order to register a new user. However, it would make sense to give new users the option to set their preferences at the time they join, which would mean that the sign-up page would have all the same fields as the user preferences page, in addition to the new ones. It would instead seem to be easier to put all these fields on the same page and use a conditional tag to turn off the ones that aren't always needed. This modifies the user preferences page as shown in Listing 7.4.

Listing 7.4 The new user preferences page

<c:if test="${!user7.isLoggedIn}">
  <tr>
    <td class="label">Your name:</td>
    <td><input type="text" name="name"></td>
  </tr>

  <tr>
    <td class="label">User name:</td>
    <td><input type="text" name="username"></td>
  </tr>

  <tr>
    <td class="label">Password:</td>
    <td><input type="password" name="password"></td>
  </tr>
</c:if>

<tr>
  <td class="label">Background color:</td>
  <td><input type="text" name="bgColor"
       value='<c:out value="${user7.bgColor}"/>'></td>
</tr>

<tr>
  <td class="label">Banner color:</td>
  <td><input type="text" name="bannerColor"
       value='<c:out value="${user7.bannerColor}"/>'></td>
</tr>

<tr>
  <td class="label">Text color:</td>
  <td><input type="text" name="textColor"
       value='<c:out value="${user7.textColor}"/>'></td>
</tr>

To ensure that this will work, consider what will happen when the user clicks the submit button and goes to preferences_handler.jsp in each of the circumstances this page will need to handle. In both cases, the result will be to set all the form variables and then set the save property. This is the right thing to do, regardless of whether the user is signing up or changing preferences. The latter case has already been considered and is known to work. In the former case, the initial jsp:setProperty will set the additional user name and password fields; then, when the save property is set, the bean will recognize that there is not yet a userId specified and hence will do a SQL insert instead of an update.

The upshot of all this is that once again, by putting all the hard work in the model layer, the task of creating the view has been greatly simplified. If we did not have beans at our disposal, we would need separate pages for new users and existing users and then two other pages to handle saving the data in each of these cases. As an exercise, consider how these cases would be handled if all this work needed to be done using only sql:query and sql:update tags!