in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 84 85 86 87 88 89 < 90 > 91 92 93 94 95 96 .. 166 >> Next

Item 28: Problems with Filters
Most Web developers want to craft applications that handle user requests, accommodate modifications, and render pertinent content in an efficient manner. Often this means migration to a controller that processes requests and renders different views based on user selections. More often than not, the Model-View-Controller (MVC) pattern is used because it allows components to be separated from application interdependencies, which enables modifications to be made in an easy fashion.
The three elements of the MVC pattern are as follows:
A model that represents the application data and business logic that dictates the availability and changes of the application data.
A view that renders the model data and forwards user input to the controller.
A controller that determines presentation views and dispatches user requests.
Applications that adhere to the MVC design pattern decouple application dependencies, which means that component behavior can be separated and modifications to one layer, say the model tier, can be made and will not affect the view and controller tiers. This improves application flexibility and reusability because changes don't reverberate through the entire system. The MVC paradigm also reduces code duplication and makes applications easier to maintain. It also makes handling data easier, whether you are adding new data sources or changing data presentation, because business logic is kept separate from data.
The MVC solution seems simple enough, but the implementation of simple solutions can often be a different matter. Application controller implementations can assume many forms. Sometimes they involve having several applications pass requests among each other with hard-coded navigation context paths. In many JavaServer Page solutions, a left navigation page is incorporated into a home page that includes header, footer, and content pages, and requests propagate between all of these pages. Problems arise when modifications need to be made to those pages that share a link, perhaps a header and a footer page, because corrections need to be made to both pages. Additionally, the management of parameters between applications becomes cumbersome, and changes don't always propagate properly.
Problems with Filters 245
Depending on your situation, the JSP solution described above could be right for your deployment, but for enterprise deployments, the appropriate solution is a single servlet or JavaServer controller page that serves as a common entry point for all application requests. When a single servlet controller is implemented, it makes examining and monitoring all process requests easy.
In addition to servlet controller implementations in MVC applications, filters are needed to enhance request processing because of their ability to transform requests and forward responses. Filters also allow applications to log, audit, and perform security role administration operations prior to request forwarding, which previously had to be performed by additional code and requests.
Filters are generally used to modify request headers and data. More importantly, filters allow requests to be processed in a chainlike fashion. Filter chain implementations locate chain items sequentially through the doFilter method and pass along request and response objects through the chain. When the last filter in the filter chain has been processed, the target servlet is summoned.
Figure 28.1 visually demonstrates how a Web controller implementation should be developed. All configuration data should be aggregated in the deployment descriptor (web.xml), including servlet, filter, and JSP mappings. With this architecture, all requests are "filtered" prior to being passed on to the servlet controller that passes control to the JSP visualization applications. The persistence layer on the outer perimeter interacts with both the servlet and JSP applications.
The J2EE specification defines a deployment descriptor as an XML file that describes components between the application assembler and the deployer. In Listing 28.1 all JSP and servlet mappings are migrated to the web.xml file. All controller management emanates from the web.xml file, which simplifies the application's deployment and facilitates modifications.
As part of the deployment described below, the Front Controller pattern is applied to the controller implementation in the program. With this pattern, a controller component manages the user requests, and a dispatcher component manages navigation and user views.
Figure 28.1 Web controller architecture.
246 Item 28
01 package org.javapitfalls.item28
02 import*;
03 import java.util.*;
04 import javax.servlet.*;
05 import javax.servlet.http.*;
07 public class ControllerServlet extends HttpServlet {
09 public void service(HttpServletRequest req,
10 HttpServletResponse res)
11 throws ServletException, {
13 String direction = req.getParameter("direction");
Previous << 1 .. 84 85 86 87 88 89 < 90 > 91 92 93 94 95 96 .. 166 >> Next