JSP里面涉及到的标签扩展和标签库!
解决方案 »
- 求解,学习java重点知识是什么?
- 关于灌水贴
- 想认识一些了解框架之类的朋友。
- html中<style>中内容写法的问题:<style>里面开头有用“*”、“.”、“#”、还有什么都没有。这每种开头都是什么意思啊!
- ecplise如何看SWING的图形界面呢
- 关于图片显示的问题,100分
- applet的更新问题,程序改动后,调用的还是原来的class,急!!!
- 我是一个刚刚学习java的菜鸟,写了一点程序就是不能执行,编译通过,看了老半天也没有看出毛病来!
- (肯定给分)用java开发软件,采用谁家的开发环境,最好的书籍是什么?一般前后台用什么软件?
- 反射为什么没有接收内容呢?
- sos!!!!!!!!!!!!!!图象接口
- DateFormat有没有getDateInstance方法。如果有在那个来里面!谢谢了等带。。。
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.