Java Reference
In-Depth Information
Line 20
: This line fetches all the initialization parameters from the deployment
descriptor.
Line 22
: This line adds these parameters to the response.
Listing 3-58 illustrates the configuration of the response filter in the deployment descriptor.
Listing 3-58. Configuring Simple Response Filter
1.<filter>
2.<filter-name>HTML5</filter-name>
3.<filter-class>com.apress.filters.ResponseHeaderFilter</filter-class>
4.<init-param>
5.<param-name>X-UA-Compatible</param-name>
6.<param-value>IE=edge,chrome=1</param-value>
7.</init-param>
8.</filter>
9.<filter-mapping>
10.<filter-name>HTML5</filter-name>
11.<url-pattern>/*</url-pattern>
12.</filter-mapping>
Line 5 to 6
: These lines define the init parameters.
Front Controller
For web applications to be maintainable, all requests must pass through a common central
component. The lack of a centralized mechanism leads to the following problems:
There is no centralized component for view management, which results in code
redundancy and code scattering across the views.
Views are often encoded with view navigation logic. This results in intermingled
view content and view navigation.
The Front Controller pattern provides a centralized access for the request handling to provide
content retrieval, view management, navigation, validation, error handling, centralized security
control, and so on. The Front Controller pattern is best implemented with a servlet. Using a
centralized servlet to handle all requests and responses provides the following advantages:
It provides a single location from which to control decisions related to
authentication and authorization.
All URLs that the front controller is required to handle can be mapped to this
servlet.
It provides a centralized access point to support the view management and
navigation.
You can apply common logic to several views.
It provides the separation of the presentation logic from the navigation and
business logic. This leads to loose coupling between the two.
