1、英文原文: Using XML and JSP together Im going to assume that, like most Java programmers, you know what JavaServer Pages (JSP) and Extensible Markup Language (XML) are, but you may be a little unclear on how you can use them. JSP use is pretty easy to defend. It allows you to design a Website built from
2、 files that look and act a lot like HTML. The only difference is that JSPs also act dynamically - for example, they can process forms or read databases - using Java as a server-side scripting language. XML use is more difficult to justify. While it seems as if every new product supports it, each one
3、 seems to be using XML for a different purpose. In this article, you will learn to design a system using XML in a fairly modest way. Many Websites have vast collections of data that are displayed in a more or less standard way. I will design a system that uses XML files to store data on a Web server
4、 and JSP files to display that data. XML versus relational databases But wait, you may ask, youre using XML to store data? Why not use a database? Good question. The answer is that for many purposes, a database is overkill. To use a database, you have to install and support a separate server process
5、, which often also requires installing and supporting a database administrator. You must learn SQL, and write SQL queries that convert data from a relational to an object structure and back again. If you store your data as XML files, you lose the overhead of an extra server. You also gain an easy wa
6、y to edit your data: just use a text editor, rather than a complicated database tool. XML files are also easier to back up, to share with your friends, or to download to your clients. You can also easily upload new data to your site, using FTP. A more abstract advantage of XML is that, being a hiera
7、rchical rather than a relational format, it can be used in a much more straightforward manner to design data structures that fit your needs. You dont need to use an entity relationship editor nor normalize your schema. If you have one element that contains another element, you can represent that dir
8、ectly in the format, rather than using a join table. Note that for many applications, a filesystem will not suffice. If you have a high volume of updates, a filesystem may get confused or corrupted by simultaneous writes; databases usually support transactions, which allow concurrency without corrup
9、tion. Further, a database is an excellent tool if you need to make complicated queries, especially if they will vary from time to time. Databases build indexes, and are optimized for keeping the indexes up to date with a constantly changing data set. Relational databases also have many other advanta
10、ges, including a rich query language, mature authoring and schema design tools, proven scalability, fine-grained access control, and so on. (Note: You can use simple file locking to provide a poor mans transaction server. And you can also implement an XML index-and-search tool in Java, but thats a t
11、opic for another article.) In this case, as in most low-to-medium volume, publishing-based Websites, you can assume the following: most of the data access is reads, not writes; the data, though potentially large, is relatively unchanging; you wont need to do complicated searches, but if you do, youl
12、l use a separate search engine. The advantages of using a mature RDBMS fade, while the advantage of using an object-oriented data model come to the fore. Finally, its entirely possible to provide a wrapper for your database that makes SQL queries and translates them into XML streams, so you could ha
13、ve it both ways. XML becomes a more robust, programmer-friendly frontend to a mature database for storing and searching. (Oracles XSQL servlet is one example of this technique.) The application: An online photo album Everybody loves photos! People love showing pictures of themselves, their friends,
14、their pets, and their vacations. The Web is the ultimate medium for self-indulgent shutterbugs - they can annoy their relatives from thousands of miles away. While a full-fledged photo album site would require a complicated object model, Ill focus on defining a single Picture object. (The source cod
15、e for this application is available in Resources.) The object representing a picture needs fields representing its title, the date it was taken, an optional caption, and, obviously, a pointer to the image source. An image, in turn, needs a few fields of its own: the location of the source file (a GI
16、F or JPEG) and the height and width in pixels (to assist you in building tags). Here there is one neat advantage to using the filesystem as your database: you can store the image files in the same directory as the data files. Finally, lets extend the picture record with an element defining a set of thumbnail images for use in the table of contents or elsewhere. Here I use the same concept of image I defined earlier. The XML representation of a picture could look something like this: Alex On The Beach 1999-08-08 Trying in vain to get a tan alex-beach.jpg 340