Conclusions

In this chapter, we have learned JSP: JavaServer Pages. We have looked at their syntax and discussed the meaning of their basic constructs. The point we have emphasized throughout is that they are construction material of outstanding flexibility and versatility that requires a conscious design effort in order to be put to good use. Two uses we have emphasized are: the main servlet of the application, and output template files. We strongly recommend against using JSP pages as containers for back-end code.

 

In terms of the Model-View-Controller pattern, think of JSP as presentation logic, ignorant (as much as possible) of the underlying model but carrying all of the view information and some of the controller. As a project grows, we suggest that the bean takes the role of control, the model is confined to the classes controlled by the bean, and JSP is purely view, including view of the controller.

 

One component of the design that is conspicuously absent from this chapter is XML. We have shown how a JSP file can be a valid XML file (and thus produced and validated by an XML editor), but the relationship between JSP and XML is much deeper than that, we believe. One major use of JSPs is to manage an associated JavaBean (or several beans). The beans themselves can serve as processors of incoming and outgoing streams of information. XML, as you know, is ideally suited for encoding streams of information, and Java has the best tools for processing XML. Putting the two together, it is natural to organize an application as a network of JSP pages and associated beans that produce and consume XML streams. The initial source of an XML stream may be a database or an email store or anything else, as long as it is XML. This is what we will do in the next chapter.