That is kind of an open-ended question, but here are two alternatives and some problems associated with them:
1. Filter -- some containers require that a request really does map to a resource, so even if the Filter mapping matched the request you could end up with 404 errors in the case where the resource doesn't exist. One way to avoid this would be to have each request map to a JSP directly, but that would be pretty confusing if the controller decided to map the request to some other JSP (or some other, similar view resource) instead of passing it down the chain to the indicated JSP. Some Actions have some kind of switching behavior to route the request to one of a number of view resources. 2. JSP -- the controller normally passes the request to a view resource (like a JSP) but doesn't produce the response directly. JSPs are best suited to producing a response (usually HTML) directly, where a servlet better matches the needs of writing a controller. Other view-oriented technologies are similar to JSPs, and many use their own servlet to process the requests anyway. Since those don't work so well, a Servlet turns out to be a good match for the needs of the controller component in comparison. It sounds like you might have something else in mind -- what alternative implementation strategy are you thinking of? -Max On Mon, 2003-09-08 at 19:24, virupaksha wrote: > Dear All, > > I have a simple doubt, > Why servlet is considered as controller in in MVC framework, > > Can any one please answer.. > > Regards, > viru > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
