Navigation in the ocean of pages

3.4 navigate to the ocean of pages

In the first two chapters of this book, we have covered JSF's support for navigation from one page to another. Conceptually, it is very similar to struts's actionforward. However, it does not have an exact name like "actionforward", so it is called a JSF navigation system.

The core of the navigation system is the navigation processor, which is actually a piece of code that decides which page to load next. In this book, we are describing the default behavior of the navigation processor (you can also replace and decorate the navigation processor; See details in appendix C ). The operation of the navigation processor is responsible for responding to Action events, while action events are usually executed by the Action source (components that capture user action operations, such as buttons or hyperlinks ). The Action source can be associated with the action method that returns a logical result after executing some application logic, or a logical result value can be hardcoded directly.

The navigation processor runs on a set of navigation rules, which define all possible navigation paths in the application. A navigation rule defines which page to select for a specific page or a group of pages. Each path to the page is expressed as a navigation case ). The navigation case is selected based on logical results (obtained from the component itself or its associated action methods) and/or expressions for the executed action method itself.

The navigation rules are defined in the application configuration file using XML. Some ides also allow you to visually edit navigation rules. Figure 3-13 shows the visual navigation editor of Sun Java Studio creator [sun, creator. The figure shows three pages: placeorder. jsp, confirmorder. jsp, and orderentry. jsp.

Figure 3-13 edit the page navigation in Sun Java Studio creator [sun, creator. The corresponding XML source code is shown in code list 3-6.

Here we use placeorder. JSP has a navigation rule. There are two navigation cases: one is to navigate to confirmorder when the result is "success. JSP; the other is to navigate to orderentry when the result is "failure. JSP. There is no navigation rule for confirmorder. jsp -- it is the end point. There is a navigation rule for ordererror. jsp. In one case, if the result is "retry", placeorder. jsp is returned.

The beautiful icons generated by this tool are the regular faces configuration files and the <navigation-Rule> and <navigation-case> element configurations. Figure 3-14 shows the structure of these elements. In the code list, 3-6 is the XML source code that defines the navigation rules shown in Figure 3-13.

Code List 3-6 shows the XML source code of the navigation rule in Figure 3-13

Figure 3-14 navigation consists of navigation rules, which are defined by the <navigation-Rule> element in the JSF configuration file. (Optional) the navigation rule can specify the page to which it applies, that is, it is specified by the <from-View-ID> element. Each <navigation-Rule> has one or more <navigation-case> elements, which must have the <to-View-ID> element to specify the next page to be loaded. You can also use the <from-outcome> element to specify the result or use the <from-Action> element to specify the action. If the <redirect> element is specified, JSF will send HTTP redirection instead of internal forwarding to the new view. The <navigation-Rule> and <navigation-case> elements have optional <description>, <display-Name>, and <icon> elements, which are usually used by tools.

In the code list, JSP uses the <from-View-ID> and <to-View-ID> elements to reference. Each view has an identifier, that is, a simple file name. The file name can be a JSP name or another resource name, but it must start with a slash (/) relative to the root directory of the Web application. There can be more than one navigation rule for the same <from-View-ID> value; JSF will process them as a large and complete navigation rule. This is useful when an application has multiple different configuration files with different navigation rules. This situation occurs when different teams in the project work on different parts of the application.

The last navigation case specifies the <redirect> element, which tells JSF to send HTTP redirection to the new view, which is opposite to forwarding users to the view internally. In JSP, this means that the user will see the URL of the webpage that she/he is currently accessing. This is different from the URL of the previous webpage (Remember, the JSF page will be sent back for itself ). The <redirect> element also forces the Web container to process requests to the new view, which means it can be processed by other application logic (similar to servlet filter) that may exist in other applications ).

It should also be noted that the result settings do not correspond to specific resources, they are only logical results. This is critical because we do not need to associate results with specific resources. If you use the results in this way, it is very easy to change the actual resources corresponding to the results, without changing the meaning of the results (that is, you do not need to change the Java code ). Table 3-8 shows some common result strings.

Table 3-8 common result strings

Result	Meaning
Success	The operation is successful. Move to the next logic page
Failure	The operation failed. Display a page to tell users why they failed and what they should do
Error	A system error occurred. Displays a system error page
No results	No matching user query records. Display query page again
Login	You must log on first. Show logon page
Logout	Log out of the application system. Display logout page

The Order example has three running results: "success", "failure", and "retry ". The first two are dynamic and they are returned from the action method. Orderentry. jsp has an htmlcommandbutton component:

When you click this button, the placeorder method is executed, and the method returns the string "success" or "failure ". The action method can also return NULL; in this case, the current page is only re-displayed (for details about how to compile the action method, see Chapter 13th ).

Unlike "success" and "failure", "retry" results are static, so it does not need to be produced by Action methods at all. It is hardcoded to the ordererror. jsp page:

The result of clicking this button remains unchanged-it is always "retry ".

Even if two results are dynamic and one result is static, navigation rules do not actually distinguish them. This means that you can change the dynamic results to static without changing the rules, and vice versa.

To ensure that a result is generated by a specific action method, you can embed the <from-Action> element into the <navigationcase> element:

This case will not be executed unless the "success" result is generated by the ordermanager. placeorder action method. This is useful when two different action methods generate the same result string. If you want to navigate the case by relying only on the name of a specific action method, you can even ignore the <from-outcome> element:

This case shows that as long as the Action Method ordermanager. placeorder is executed, the view confirmorder. jsp will be loaded.

So far, the navigation rules we have discussed are for specific pages. You can also define navigation rules for all pages (like struts's global actionforward) or for a group of pages. If the value of the <from-View-ID> element is defined as an asterisk, the rule is global:

In this example, the value of the <from-View-ID> element is an asterisk. This rule applies to all pages. At any time, as long as the result is "login", the page login. jsp will be loaded, and as long as the result is "logout", the page logout. jsp will be loaded. You can also ignore the <from-View-ID> element to achieve the same effect.

To specify a set of pages, you must use wildcards in the <from-View-ID> element (asterisk Wildcards are not supported in other places except strings ). Therefore, if you want to match all pages starting with "froglegs", the value of the element should be "froglegs *". If multiple rules start with "froglegs", JSF selects the longest one.

A more common practice is to map rules to the entire directory:

This specifies a navigation rule that applies to all pages under the context-relative directory "initialize ate. These navigation cases reference pages in the same directory, but this is not required.

It is reasonable to note that if an application has many navigation rules, place them in a separate application configuration file instead of in the master configuration file.

In all the examples shown above, we omitted several optional elements that can be used for navigation rules and navigation cases. They are <description>, <display-Name>, and <icon> elements. The following is the global navigation rule definition after these elements are added:

Here, we add a description, a display name, and an icon to the navigation rule. The description and display name are also added to each navigation case (the navigation case can also contain icons, but they are not specified here ). <Description> the element can be used to communicate with other people in the team about navigation rules (or display the settings to yourself later ). Other elements are usually used to visually edit navigation rules.

It is a good idea to give a description of the navigation rule so that other developers can understand its purpose.

Here we end the brisk JSF navigation journey. You can see more examples when building the case in Part 2 and Part 3.