JSP+MySQL网上教学系统Eclipse 第14页
<br/> to ensure XML compliance. (If this doesn't make much sense, you can check out the XML specification and the developerWorks article about XHTML, listed in Resources.) Similar rules are applied to image tags, and in XHTML 1.1 (recently coming of age) most font properties and other styling move into CSS stylesheets. Still, most standard HTML documents convert easily to XHTML 1.0, which means they can be read directly with any XML-compliant parser, such as Apache Xerces, and manipulated as XML.
"What's the big deal?" you ask. The big deal is that XML quickly is becoming the global standard for inter- and intra-application communication. Passing data around in an XML format lets any other application that employs basic XML data-handling facilities use your application's data easily. Imagine being able to communicate with credit card companies for e-commerce simply by moving your data into an XML format! Many times, your presentation of data needs to be exchanged with other companies as well. The most common case is the portal application, which receives content from a variety of providers (weather, stock quotes, and news, for example), often with branding from the provider. JSP pages, however, with their mix of code and custom tag libraries, cannot function well in this environment.
JSP pages are rarely well-formed XML documents, never mind conforming to XHTML, a markup language that doesn't allow the various JSP custom tag libraries. More important, though, is that the code snippets inserted in JSP pages are not any form of markup and will create loads of parser errors once they are processed by another application.
Before you go quoting me on this, let's get the whole story out there. If the application were to allow the JSP page to be evaluated by the original client, the result would be pure HTML (or WML, VoXML, and so on). Most applications that request this data, however, employ some form of caching, as network round-trips are very expensive. In these cases, the cached page returns stale data. In those cases, then, you'd probably prefer to return pure XML-compliant results, preferably in a static form. And it is in those cases that JSP technology cannot help; JSP pages must always be evaluated at runtime to remove the JSP code scriptlets and tag libraries.
Apply the litmus test: Can some other presentation technology do this? The answer is yes. The decided leader in this arena is the Apache Cocoon project, which is based entirely on XML and an application of XSLT stylesheets (which can be applied either at runtime or statically). Because XML Server Pages (called XSP in the Cocoon framework) are actually XML documents, they are always XML-conformant. Other technologies like Tea and Enhydra XMLC that allow the input of a pure markup language page also allow this, although they do not mandate it. In these cases, the user can use XHTML or standard HTML. Still, this is better than the JSP case, where well-formed XML cannot be accomplished statically.
<< 上一页 [11] [12] [13] [14] [15] [16] 下一页