To change the application name and welcome text, we first need to find the JSPX view, which shows the home page of the web application and then find the property in the application.properties file, which is used by the JSPX view to show the application name and welcome text. Alternatively, you can look at the property keys of the labels that you want to change in the application.properties file, followed by using your IDE to search for JSPX files, which make use of those property keys.

Let's first find the JSPX view that shows the home page of the flight-app application. In the webmvc-config.xml file, the following <view-controller> element suggests that when the request is received at the web application root /, then the view name is index:

<mvc:view-controller path="/" view-name="index"/>

Now, the following UrlBasedViewResolver in webmvc-config.xml suggests that we need to find the tile definition named index in the tiles definitions XML file to find the view:

<bean class="org.springframework.web.servlet.view.
     UrlBasedViewResolver" id="tilesViewResolver">
   <property name="viewClass"  
      value="org.springframework.web.servlet.view.
           tiles2.TilesView"/>
</bean>

The following TilesConfigurer configuration in webmvc-config.xml suggests where to look for tiles definitions XML to find tiles definition named index:

<bean class="org.springframework.web.servlet.view.
    tiles2.TilesConfigurer" id="tilesConfigurer">
    <property name="definitions">
      <list>
        <value>/WEB-INF/layouts/layouts.xml</value>
        <value>/WEB-INF/views/**/views.xml</value>
      </list>
    </property>
</bean>

A quick scan of XML configuration files specified by TilesConfigurer shows that the index tiles definition is defined in the SRC_MAIN_WEBAPP/WEB-INF/views/views.xml file, as shown here:

<definition name="index" extends="default">
  <put-attribute name="body" 
      value="/WEB-INF/views/index.jspx" />
</definition>

As we'll see in the Adding static views to Roo-generated web application recipe, the <put-attribute> element refers to the JSPX file responsible for showing the main content (which excludes the header, footer, and menu) of the page. So, the /WEB-INF/views/index.jspx is the file, which shows the home page of the flight-app application.

The following code shows the contents of the index.jspx file:

<div xmlns:spring="http://www.springframework.org/tags"  
    xmlns:util="urn:jsptagdir:/WEB-INF/tags/util" .. >
  
  <spring:message var="app_name" code="application_name" .../>
  <spring:message var="title" 
     code="welcome_titlepane" arguments="${app_name}" .../>
  
  <util:panel id="title" title="${title}">
    <h3>
      <spring:message code="welcome_h3" 
          arguments="${app_name}" />
    </h3>
    <p>
      <spring:message code="welcome_text" />
    </p>
  </util:panel>
</div>

The <message> tag of Spring's tag library retrieves messages and labels from the resource bundle, which are Roo-generated application.properties and messages.properties files in case of the flight-app application. The code attribute identifies the property key whose value needs to be obtained from the resource bundle. The var attribute identifies the variable to which the returned property value is assigned. The arguments attribute specifies the arguments that need to be passed to the <message> tag, which are typically used by the <message> tag implementation to fill placeholders specified in the message or label retrieved from the resource bundle.

The <panel> tag is one of the custom tags installed by Roo when the controller all command was executed. The <panel> tag is used to show a collapsible panel. To see the implementation of the <panel> tag, refer to the /WEB-INF/tags/util/panel.tagx file.

The following table shows the properties file in which the messages and labels, as specified by the <message> tags in the index.jspx file, are located and their value:

The {0} in the value of the welcome_titlepane and the welcome_h3 represents a placeholder, which is filled by the value specified in the arguments attribute of the <message> element.

The given table shows that if we change the application_name property, then it will change the application name as shown on the home page. And if we change the welcome_text property, then it will change the default welcome text.

The menu.jspx file shows the menu options in the Roo web application. The following table describes the tags that make up the menu.jspx file:

The following attributes are applicable to all the tags installed by Spring Roo (which includes the <menu>, <item>, and <category> tags for menu):

<menu:item id="i_flightdescription_new" 
  messageCode="global_menu_new" 
  url="/flightdescriptions?form"     
  z="DFDc4F2kZR5ysns4ZeMk5pr3E84="/>

Let's consider the /WEB-INF/views/flights/create.jspx view, which shows the form for creating the Flight entities. The following code shows the content of create.jspx:

<div xmlns:field="urn:jsptagdir:/WEB-INF/tags/form/fields" xmlns:form="urn:jsptagdir:/WEB-INF/tags/form" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:spring="http://www.springframework.org/tags" ..>

   <form:create id="fc_sample_roo_flightapp_domain_Flight" 
       modelAttribute="flight" 
       path="/flights" render="${empty dependencies}" 
       z="/JE8B/QGFrFLKszYDOjyDJjnTPc=">
      <field:datetime 
         dateTimePattern="${flight_departuredate_date_format}" 
         field="departureDate" 
         id="c_sample_roo_flightapp_domain_Flight_departureDate" 
         z="BtcAuQvStTt55J3J6zFybfhkSxA="/>
     ....
      <field:select field="flightDescription" 
         id=".." itemValue="flightDescId" 
         items="${flightdescriptions}" 
         path="/flightdescriptions" required="true" 
         z="MPt8rEJwJ7fZPqUZPDn6K7+A8OE="/>
   </form:create>
   ....
</div>

A couple of interesting things to notice about the create.jspx file generated by Roo are as follows:

As we can see, Roo intelligently decided that the <datetime> tag should be used for creating fields corresponding to the Date type, such as the departureDate field of the Flight entity. Roo also interpreted the @ManyToOne relationship between the Flight and FlightDescription JPA entities and created a drop-down box (using the <select> tag) for selecting flight descriptions. As the @ManyToOne relationship between the Flight and FlightDescription entities is also annotated with @NotNull (JSR-303 annotation), Roo translates that dependency on the user interface side by setting the required attribute to true for the <select> tag.

Now, let's look at how the dependencies variable is used by the <create> tag to decide whether to render the create Flight form or not. One of the things that you will notice when you go about creating a Flight entity is that it will ask you to first create FlightDescription, as shown in the following screenshot:

As shown in the screenshot, instead of displaying the Create new Flight form, the web application displays a note saying that we need to first create flight descriptions. The decision to show the note is taken by the dependencies variable, as shown again here:

<form:create id="fc_sample_roo_flightapp_domain_Flight" 
       modelAttribute="flight" 
       path="/flights" render="${empty dependencies}"
...

The dependencies variable is added to the request by the FlightController. The FlightController identifies the dependencies of the Flight JPA entity based on the relationships in which it participates. As the Flight entity has a not null many-to-one relationship with the FlightDescription entity, the FlightController adds it as a dependency in the dependencies variable, as shown here in the contents of the FlightController_Roo_Controller.aj file:

@RequestMapping(params = "form", method = RequestMethod.GET)
   public String FlightController.createForm(Model model)
   {
      model.addAttribute("flight", new Flight());
      addDateTimeFormatPatterns(model);
      List dependencies = new ArrayList();
      if (FlightDescription.countFlightDescriptions() == 0)
      {
         dependencies.add(new String[]{"flightDescription", 
            "flightdescriptions"});
      }
      model.addAttribute("dependencies", dependencies);
      return "flights/create";
   }

The createForm method is responsible for rendering the form for creating the Flight entity instances. The given code shows that if no FlightDescription entity instances are found, the createForm method adds a String[] to the dependencies model attribute. The dependencies attribute contains the dependencies, which are not currently available for creating the Flight instances. The form for creating Flight entities is rendered only if the dependencies attribute is empty, something which we have already seen.

We saw earlier that we can switch an element in the JSPX file from the Roo-managed mode to the user-managed mode. In some scenarios, you may want to switch back from theuser-managed mode to the Roo-managed mode. Let's look at how we can do so:

We saw that Spring Roo does a lot of heavy lifting to create the user interface of the web application. This includes creating JSPX files, installing custom tags, creating Spring Web MVC controllers, creating web application context XML file, creating the web application deployment descriptor, creating tiles definitions, installing themes, and so on. We also saw that the value of the required attribute of the <select> tag for showing flight descriptions was set to true because the Flight JPA entity participates in a not null many-to-one relationship with the FlightDescription entity.

Let's assume that we want the text field of the departureDate field also to be mandatory to create the Flight entity. You have the option to annotate the departureDate field of the Flight JPA entity with @NotNull JSR-303 annotation and let Roo take care of setting the required attribute's value to true for the departureDate text field. Let's further assume that we don't want to make any changes to the Flight entity and a date must be entered in the departureDate field when creating the Flight entity from the user interface. We can do this by simply setting the required attribute's value to true, as shown here:

<field:datetime 
   dateTimePattern="${flight_departuredate_date_format}" 
   field="departureDate" required="true"
   id="c_sample_roo_flightapp_domain_Flight_departureDate" 
        z="BtcAuQvStTt55J3J6zFybfhkSxA="/>

As we have changed the default value of the required attribute from false to true, we have effectively modified the element; therefore, Roo will go ahead and set the value of the z attribute to user-managed. A user-managed element in Spring Roo doesn't participate in round tripping; therefore, if you make any modifications to the departureDate field of the Flight entity, then Roo will not make any corresponding modifications to the departureDate element in the create.jspx file. For instance, if you remove the departureDate field from the Flight entity, then Roo will not remove the departureDate element from create.jspx. If you want your modified form element to be Roo-managed again, all you need to do is set the value of the z attribute to ?. The value of ? instructs Roo to re-calculate the value of the z attribute based on the current attributes and their values, making it possible for Roo to figure out if changes happen to the form element in the future.

As we just discussed, you can take control of Roo-managed form elements in JSPX views by adding or modifying one or more attributes. It is recommended that after you make changes to a form element, revert back to the Roo-managed mode by setting the value of the z attribute to ?. In Roo-managed mode any modification to the JPA entities is taken care of by Roo, saving the effort to make adjustments to the views.