JSP里面涉及到的标签扩展和标签库!

解决方案 »

  1.   

    http://www-900.ibm.com/developerWorks/java/logicview/index.shtml
      

  2.   

    A tag library example using DBTags
    One of the first things that a new JSP programmer hears, usually from well-intentioned friends and experts, is not to use scriptlets. Instead, they tell the new JSP programmer to use custom tags. Custom tags are a means by which the JSP platform's capabilities are extended: custom XML-style tags, tied to code libraries, implement the desired functionality. We'll see how well they work, in our next example.The Jakarta TagLibs Project is a subproject of the Jakarta Project (see Resources), the official reference implementation of the Java Servlet and JavaServer Pages technologies.One of the packages developed under the auspices of the Jakarta TagLibs Project is the DBTags custom tag library (formerly known as the JDBC tag library). JSP page using DBTags
    <HTML>
    <HEAD>
    <TITLE>Jakarta DBTags example</TITLE>
    </HEAD>
    <BODY><%@ taglib uri="http://jakarta.apache.org/taglibs/dbtags" prefix="sql" %><%-- open a database connection --%><sql:connection id="conn1">
      <sql:url>jdbc:mysql://localhost/test</sql:url>
      <sql:driver>org.gjt.mm.mysql.Driver</sql:driver>
    </sql:connection><%-- insert a row into the database --%><sql:statement id="stmt1" conn="conn1">
      <%-- set the SQL query --%> 
      <sql:query>
          insert counters(page,hitCount) values('<%=request.getRequestURI()%>', 0)
      </sql:query>
      <%-- the insert may fail, but the page will continue --%>
      <sql:execute ignoreErrors="true"/>
    </sql:statement><%-- update the hit counter --%><sql:statement id="stmt1" conn="conn1">
      <%-- set the SQL query --%> 
      <sql:query>
          update counters set hitCount = hitCount + 1 where page like '<%=request.getRequestURI()%>'
      </sql:query>
      <%-- execute the query --%>
      <sql:execute/>
    </sql:statement><P>This page has been hit<%-- query the hit counter --%><sql:statement id="stmt1" conn="conn1"> 
      <sql:query>
        select hitCount from counters where page like '<%=request.getRequestURI()%>'
      </sql:query>
      <%-- process only the first row of the query --%>
      <sql:resultSet id="rset2" loop="false">
          <sql:getColumn position="1"/>
      </sql:resultSet>
    </sql:statement>times. The page counter is implemented using the Jakarta Project's
    DBTags tag library, calling JDBC indirectly.</P><%-- close a database connection --%>
    <sql:closeConnection conn="conn1"/></BODY>
    </HTML> I don't know about you, but I'm feeling a bit let down. That seems even less clear to me than the scriptlet example, and I don't know any nonprogramming HTML page designers who would be pleased with it, either. But what went wrong? After all, we followed people's advice: we got rid of the scriptlet and replaced it with custom tags.Developing custom tag libraries is relatively straightforward, but it does take some thought and it is time consuming. I often recommend that tag library authors first prototype the tag behavior using scriptlets, and then convert those scriptlets into tags. 
    An alternative is to use Allaire's JRun Server Tags (JST), which enables you to prototype tag libraries by authoring each tag as a JSP page (with a .jst extension). The JST converts that page into a tag handler at run time, so the JST technology is transparent to the client pages. Although Allaire claims that the "goal is to establish JST as a portable technology so that all members of the J2EE community can leverage its benefits" JST is currently only available in JRun. Time will tell whether JST becomes a more common means to develop tags. Meanwhile, we find that scriptlets provide a fine basis for developing a tag's business logic; after the logic is debugged, we migrate it into a tag handler class.
     
    What they don't tell you about tag libraries is this: tag design is language design. Most tag libraries written to date have been written by programmers for programmers; the semantics of those tags are geared toward other programmers. Furthermore, remember the separation of model and presentation? That isn't well supported by DBTags. The sql:getColumn tag is analogous to the jsp:getProperty action: it emits the tag's result directly into the output stream. That makes it difficult to separate using DBTags from rendering output into the desired form. The DBTags execute tag consumes the update count from any update statement sent via JDBC; only query results can be retrieved. That means we cannot find out how many rows were updated by the update statement. So we have to switch the update and insert statements; we always try to insert a new record, force DBTags to ignore any error, and then perform the update.In fairness to the DBTags tag library, it is not a bad tag library for programmers. Aside from its consumption of the update count, the code provides a fairly good mapping to JDBC. Therein lies the problem, however: the tags provide little more than a direct translation of the JDBC package. Other than hiding some exception handling, the tag library doesn't really provide any abstraction over scriptlets. It certainly doesn't help separate presentation from function.So, the real issue is not whether to use scriptlets or tags; that question is a consequence, not a cause, of the problem of separating function from presentation. The solution is to provide higher-level functionality to presentation-page authors at an appropriate level of discourse. The reason tags are considered better than scriptlets is that scriptlets, by definition, are programming, whereas tags can represent high-level concepts.