Jason Hunter of Servlet.com
examines the serious problems with JavaServer Pages or JSP. In essence: JSP came about because outputting HTML lines was a serious hardship under straight Java Servlet technology. With JSP, you can now embed Java code directly in your HTML. However, JSP still carries a lot of the Java verbosity baggage and takes a bit of effort just to output an environment variable. The solution, according to the author, is neatly solved by using a template engine such as
WebMacro instead of JSP:
So people matured in their use of JSP and started to rely more on JavaBeans. Beans were written to contain business logic code needed by the JSP page. Much of the code inside the JSP page could be moved out of the page into the bean with only minimal hooks left behind where the page would access the bean.
More recently, people have started to note that JSP pages used this way are really a "view". They're a component used to display the results of a client request. So people thought, Why submit a request directly to a "view"? What if the targetted "view" isn't the proper view for that request? After all, many requests have several possible resulting views. For example, the same request might generate a success page, a database exception error report, or a required parameter missing error report. The same request might also generate a page in English or a page in Spanish, depending on the client's locale. Why must a client directly submit its request to a view? Shouldn't the client make a request to some general server component and let the server determine the JSP view to return?
This belief caused many people to adopt what has been called the "Model 2" design, named after an architecture laid out in the JSP 0.92 specification and based on the model-view-controller pattern.
Great reading. I, myself, prefer PHP due to its simple yet powerful scripting abilities.
