BlogJava-BeanSoft's Java Blog-随笔分类-Web

分享到底：50MB的Web学习资料以及CodeLibrary.NET免费版

BeanSoft — Wed, 26 Mar 2008 01:38:00 GMT

ftp://beansoftdown:1234@219.141.70.147/ 进入目录 CodeLibrary_NET

我在先前的时候介绍过 CodeLibrary.NET 免费版(资料管理软件) 这个软件，不过可惜的是免费版逐渐下载不到了。还好，我有，现在大家可以通过这里下载（运行需要.NET 1.1）：

CodeLibAccess.zip CodeLibWeb.zip，按照顺序安装就可以了。

我先后从网上收集过很多的学习资料，用这个软件，总共有454MB那么大，不过随着岁月流逝，日月轮回，斗转星移，沧海桑田，物是人非，花开花谢，潮起潮落，人来人往，发现这些资料大部分时候都用不到，还不如取之于网，用之于网，分享一部分给大家，要不然留电脑上也是发霉。现在大家可以下载上面两个软件，然后再下载这个数据库资料：

Web.mdb.7z 用软件打开，即可浏览到内容，并可修改，文件是压缩过的15MB，解压缩后文件大小 49.5MB。

如果您只是想看资料，而不想安装或者修改，可以试试只下载这两个文件: Web.mdb.7z CodeLibViewer.zip ，不过，还需要安装.NET 1.1。

如果你有的是 .NET 2，那你只看资料的话可以下载这个：Web.mdb.7z CodeLibViewer.exe。

用查看器打开Web.mdb就行了。查看器界面如下：

下面是资料内容列表（主要是和Web开发有关的一些资料，内容并未做验证，仅供参考）：

BeanSoft 2008-03-26 09:38 发表评论

触犯天条的离奇表单验证代码

BeanSoft — Wed, 12 Mar 2008 14:12:00 GMT

晚饭后，有人在发疑问为啥编写的Struts里面的表单验证代码死活不会执行。原始代码如下：

<%@page contentType="text/html;charset=gb2312"%>
<%@taglib uri="/WEB-INF/struts-html.tld" prefix="html"%>
<html:html>
<head>
<title>welcome nexttitle>
head>
<body>
<center>
注销页面
<html:form action="/delete" enctype="multipart/form-data" onsubmit="return delete(this);">
用户名:<html:text property="username"/><br>
年  龄:<html:text property="age" value=""/><br>
地  址:<html:text property="address"/>
<br>
<html:submit value="注销"/>
<html:form>
center>
<script language="javascript">   1:  
   2: function delete(form){
   3: if(form.username.value==""||form.age.value==""||form.address.value==""){
   4: alert("请输入所有的信息!!!");
   5: return false;
   6: }
   7: else{
   8: alert("注销成功!!!");
   9: return true;
  10: }
  11: }
script>
body>
html:html>

运行症状就是不管怎么搞，都不会执行验证方法！对应的HTML代码如下：

welcome next

注销页面

用户名:

年龄:

地址:

把这个页面存成HTML代码，不论在IE还是Firefox中，都不会执行！但是又不报任何错误！难道我们写错了嘛？那当然，这个错误真是特别特别的隐蔽，因为：delete是个JavaScript的关键字！

JScript
语言参考

delete 运算符

从对象中删除一个属性，或从数组中删除一个元素。

delete expression

expression 参数是一个有效的 JScript 表达式，通常是一个属性名或数组元素。

说明

如果 expression 的结果是一个对象，且在 expression 中指定的属性存在，而该对象又不允许它被删除，则返回 false。

在所有其他情况下，返回 true。

所以，把delete这个方法名随便改成其它有效的就行了！

BeanSoft 2008-03-12 22:12 发表评论

转载:servletAPI2.1中文版.txt

BeanSoft — Fri, 02 Nov 2007 02:14:00 GMT

摘要: http://www.blogjava.net/Files/beansoft/servletAPI2.1中文版.txt.zip 译者前言：近来在整理有关Servlet资料时发现，在网上竟然找不到一份中文的Java Servlet API的说明文档，而在有一本有关JSP的书后面附的Java Servlet API说明竟然不全... 阅读全文

BeanSoft 2007-11-02 10:14 发表评论

JavaScript 三级级联菜单

BeanSoft — Mon, 22 Oct 2007 02:43:00 GMT

摘要: 2005 年的时候帮人收集整理修改的一份脚本级联菜单, 没用到 AJAX, 写死的数据. 效果自己试试就知道了. 支持主流浏览器. 自己现在看看这代码就觉得头大... 呵呵脚本就是脚本啊. 一段时间放下就看不懂了. < HTML > < HEAD > ... 阅读全文

BeanSoft 2007-10-22 10:43 发表评论

Tomcat JSP Web 开发中的乱码问题小姐

BeanSoft — Wed, 10 Oct 2007 10:20:00 GMT

1. 静态页面的乱码问题
    文件的编码和浏览器要显示的编码不一致。
    1) 检查文件原始的编码, 可以用记事本打开, 然后选择另存为来看;
    2) 给当前页面加入一个指令来建议浏览器用指定的编码来显示文件字符内容.

    3) 如果系统是英文XP,没装东亚字符集支持, 也会显示乱码.

2. JSP 页面的乱码问题
    1) page 指令有个 pageEncoding="GBK" 这个会指定当前页面保存的编码, 如果写成ISO8859-1就不能保存汉字;
    2) page 指令的 contentType="text/html; charset=ISO8859-1" 也会像静态页面一样让浏览器来优先选择一种编码.
    如果JSP乱码的话,一般就显示成?，而且不管你给浏览器选什么样的编码，它都不能正确显示
3. 表单提交的乱码问题(Tomcat 特有)
    1). POST 的乱码
        a. 首先浏览器提交表单的编码是根据表单所在页面来决定的, 而不是根据提交后的 JSP 页面的编码来决定的. 把所有的页面的编码都设置成一样的,例如 GBK.

b. 处理方式就是在获取参数之前设置编码:
request.setCharacterEncoding("GBK");

        c. 可以用过滤器的方式来解决, Tomcat 已经带了一个现成的:
        apache-tomcat-5.5.23\webapps\jsp-examples\WEB-INF\classes\filters\SetCharacterEncodingFilter.java
        web.xml

        Set Character Encoding
        filters.SetCharacterEncodingFilter

            encoding
            GBK

        Set Character Encoding
        /*

    2) GET 方式的乱码
    用 setCharacterEncoding() 不能解决. TOMCAT 的一个BUG, GET 方式传送的表单参数总是用的 ISO8859-1 编码. 我们要把它转成 GBK 方式.
    String username = request.getParameter("username");
System.out.println(username);
// 转码, 先取得原始的二进制字节数组
byte[] data = username.getBytes("ISO8859-1");
// 根据新的字符集再构造新的字符串
username = new String(data, "GBK");

小结:
所有的页面(除了最后的 GET 的乱码问题)都用统一的编码(GBK或者UTF-8), 就不会出现乱码问题.

4. 用过滤器来一次编码彻底解决表单参数的乱码问题

Tomcat 5/6 GBK 编码下完美解决中文表单问题的过滤器

BeanSoft 2007-10-10 18:20 发表评论

Tomcat 5/6 GBK 编码下完美解决中文表单问题的过滤器

BeanSoft — Tue, 09 Oct 2007 05:29:00 GMT

常见的 Tomcat 5 表单编码提交后乱码的解决方案有很多, 有改 Tomcat Connector 属性的, 有加过滤器的. 但是 Tomcat 自带的那个过滤器只解决了 POST 方式的乱码却不能处理 GET 方式的乱码. 在这里那我就给出一个不需要修改任何 Tomcat 配置文件的完美解决中文问题的过滤器的代码:

首先是我们的测试页面:

index.jsp

<%@ page language="java" import="java.util.*" pageEncoding="GBK"%>


"-//W3C//DTD HTML 4.01 Transitional//EN">

  
   
    表单测试页面

  
  
  
   "action.jsp">
   GET 方式: "name" value="GET 中文">
   
   
   
      "action.jsp" method="POST">
   POST 方式: "name" value="POST 中文">

和普通的表单没有任何区别.

然后就是表单提交页面 action.jsp:

<%@ page language="java" pageEncoding="GBK"%>

  
   参数: <%=request.getParameter("name") %>

接着是过滤器的配置文件 web.xml (用 2.5 版本也可以):

xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" 
    xmlns="http://java.sun.com/xml/ns/j2ee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
    http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <filter>
    <filter-name>TomcatFormFilterfilter-name>
    <filter-class>filters.TomcatFormFilterfilter-class>
    filter>
    
    <filter-mapping>
    <filter-name>TomcatFormFilterfilter-name>
    <url-pattern>*.jspurl-pattern>
    filter-mapping>
    
  <welcome-file-list>
    <welcome-file>index.jspwelcome-file>
  welcome-file-list>
web-app>

最后最关键的就是我们的过滤器代码了, 对 GET 方式使用请求包装器, 而 POST 方式则用 setCharacterEncoding():

package filters;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.ServletException;
import  javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
import javax.servlet.http.HttpServletResponse;

public class TomcatFormFilter implements Filter {
    /**
      * Request.java
      * 对 HttpServletRequestWrapper 进行扩充, 不影响原来的功能并能提供所有的 HttpServletRequest
      * 接口中的功能. 它可以统一的对 Tomcat 默认设置下的中文问题进行解决而只需要用新的 Request 对象替换页面中的
      * request 对象即可.
      */

    class Request extends HttpServletRequestWrapper
    {

        public Request(HttpServletRequest request) {
            super(request);
        }

        /**
         * 转换由表单读取的数据的内码.
         * 从 ISO 字符转到 GBK.
         */
        public String toChi(String input) {
            try {
              byte[] bytes = input.getBytes("ISO8859-1");
              return new String(bytes, "GBK");
            }
            catch (Exception ex) {
            }
            return null;
        }

        /**
         * Return the HttpServletRequest holded by this object.
         */
        private HttpServletRequest getHttpServletRequest()
        {
            return (HttpServletRequest)super.getRequest();
        }

        /**
         * 读取参数 -- 修正了中文问题.
         */
        public String getParameter(String name)
        {
            return toChi(getHttpServletRequest().getParameter(name));
        }

        /**
         * 读取参数列表 - 修正了中文问题.
         */
        public String[] getParameterValues(String name)
        {
              String values[] = getHttpServletRequest().getParameterValues(name);
              if (values != null) {
                for (int i = 0; i < values.length; i++) {
                  values[i] = toChi(values[i]);
                }
              }
              return values;
        }
    }
    public void destroy() {
        
    }

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpreq = (HttpServletRequest)request;
        if(httpreq.getMethod().equals("POST")) {
            request.setCharacterEncoding("GBK");
        } else {
            request = new Request(httpreq);
        }

        chain.doFilter(request, response);
    }

    public void init(FilterConfig filterConfig) throws ServletException {
    }

}

怎么样, 是不是很简单也很方便呢?

BeanSoft 2007-10-09 13:29 发表评论

Code Conventions for the JavaServer Pages Technology Version 1.x Language

BeanSoft — Sat, 22 Sep 2007 05:37:00 GMT

The source is here: http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

Article

Code Conventions for the JavaServer Pages Technology Version 1.x Language

Print-friendly Version

By Kam Hay Fung, Java Technology Consultant and Mark Roth, JavaServer Pages 2.0 Specification Co-Lead, February 2003

Articles Index

As JavaServer Pages (JSP) technology is becoming widely adopted in web-based applications, many JSP programmers and web developers embarking on developing and maintaining these applications face a dilemma like that of many Java programmers: "How do we structure JSP code that is easier to read, write and maintain consistently?"

In this article, we propose a set of standard conventions for writing JSP pages (versions 1.1 and 1.2) that should be followed on a typical software project using web components. The article draws on the Code Conventions for the Java Programming Language as a template to identify various important elements that should be addressed in a coding conventions specification (relevant to JSP technology). In particular, it addresses file names and organization, indentation, comments, directives, declarations, scriptlets, expressions, white space, naming conventions, and programming practices. As this is our first attempt at presenting a set of JSP coding conventions, we're quite interested in any feedback you may have on these recommendations. Please send all feedback to jsp-codeconv-comments@sun.com.

The JavaServer Pages 2.0 Specification, while fully backwards compatible with version 1.2, allows for a script-free programming style (without declarations, scriptlets and expressions) and has a number of new features that are expected to evolve these conventions. Where possible, this article chooses conventions that will leverage the new JSP 2.0 technology features.

Finally, we assume that you are familiar with JSP technology, Java technology and Java code conventions as already adopted by your organization for your projects. If not, we recommend that you start with Java technology here and JSP technology here.

Why Have Code Conventions?

Code conventions are important to programmers and web content developers for a number of reasons:

They improve the readability of software artifacts
They reduce training management and effort
They leverage organizational commitment towards standardization

File Names and Locations

File naming gives tool vendors and web containers a way to determine file types and interpret them accordingly. The following table lists our recommended file suffixes and locations.

File Type File Suffix Recommended Location JSP technology .jsp // JSP fragment .jsp // .jspf /WEB-INF/jspf// cascading style sheet .css /css/ JavaScript technology .js /js/ HTML page .html // web resource .gif, .jpg, etc. /images/ tag library descriptor .tld /WEB-INF/tld/

There are a few things to keep in mind when reading the table above. First, is the root of the context of the web application (the root directory inside a .war file). Second, is used to provide refined logical grouping of dynamic and static web page contents. For a small web application, this may be an empty string.

Third, we use the term JSP fragment to refer to a JSP page that can be included in another JSP page. Note that in the JSP 2.0 Specification, the term "JSP segment" is used instead as the term "JSP fragment" is overloaded. JSP fragments can use either .jsp or .jspf as a suffix, and should be placed either in /WEB-INF/jspf or with the rest of the static content, respectively. JSP fragments that are not complete pages should always use the .jspf suffix and should always be placed in /WEB-INF/jspf. Fourth, though the JSP specification recommends both .jspf and .jsp as possible extensions for JSP fragments, we recommend .jspf as .jsf might be used by the JavaServer Faces specification.

Finally, it is in general a good practice to place tag library descriptor files and any other non-public content under WEB-INF/ or a subdirectory underneath it. In this way, the content will be inaccessible and invisible to the clients as the web container will not serve any files underneath WEB-INF/.

An optional welcome file's name, as declared in the welcome-file element of the deployment descriptor (web.xml), should be index.jsp if dynamic content will be produced, or index.html if the welcome page is static.

When internationalizing JSP files, we recommend that you group JSP pages into directories by their locale. For example, the US English version of index.jsp would appear under /en_US/index.jsp whereas the Japanese version of the same file would appear under /ja_JP/index.jsp. The Java Tutorial provides additional information about internationalizing Java code in general, and the book Designing Enterprise Applications with the J2EE Platform provides information about internationalization for web applications.

File Organization

A well-structured source code file is not only easier to read, but also makes it quicker to locate information within the file. In this section, we'll introduce the structures for both JSP and tag library descriptor files.

JSP File / JSP Fragment File

A JSP file consists of the following sections in the order they are listed:

Opening comments
JSP page directive(s)
Optional tag library directive(s)
Optional JSP declaration(s)
HTML and JSP code

Opening Comments

A JSP file or fragment file begins with a server side style comment:

<%-- - Author(s): - Date: - Copyright Notice: - @(#) - Description: --%>

This comment is visible only on the server side because it is removed during JSP page translation. Within this comment are the author(s), the date, and the copyright notice of the revision, an identifier and a description about the JSP page for web developers. The combination of characters "@(#)" is recognized by certain programs as indicating the start of an identifier. While such programs are seldom used, the use of this string does no harm. In addition, this combination is sometimes appended by "$Id$" for the identification information to be automatically inserted into the JSP page by some version control programs. The Description part provides concise information about the purpose of the JSP page. It does not span more than one paragraph.

In some situations, the opening comments need to be retained during translation and propagated to the client side (visible to a browser) for authenticity and legal purposes. This can be achieved by splitting the comment block into two parts; first, the client-side style comment:

and then a shorter server side style comment:

<%-- - @(#) - Description: --%> JSP Page Directive(s)

A JSP page directive defines attributes associated with the JSP page at translation time. The JSP specification does not impose a constraint on how many JSP page directives can be defined in the same page. So the following two Code Samples are equivalent (except that the first example introduces two extra blank lines in the output):

Code Sample 1:

<%@ page session="false" %> <%@ page import="java.util.*" %> <%@ page errorPage="/common/errorPage.jsp" %>

If the length of any directive, such as a page directive, exceeds the normal width of a JSP page (80 characters), the directive is broken into multiple lines:

Code Sample 2:

<%@ page session="false" import="java.util.*" errorPage="/common/errorPage.jsp" %>

In general, Code Sample 2 is the preferred choice for defining the page directive over Code Sample 1. An exception occurs when multiple Java packages need to be imported into the JSP pages, leading to a very long import attribute:

<%@ page session="false" import="java.util.*,java.text.*, com.mycorp.myapp.taglib.*, com.mycorp.myapp.sql.*, ..." ... %>

In this scenario, breaking up this page directive like the following is preferred:

<%-- all attributes except import ones --%> <%@ page ... %> <%-- import attributes start here --%> <%@ page import="java.util.*" %> <%@ page import="java.text.*" %> ...

Note that in general the import statements follow the local code conventions for Java technology. For instance, it may generally be accepted that when up to three classes from the same package are used, import should declare specific individual classes, rather than their package. Beyond three classes, it is up to a web developer to decide whether to list those classes individually or to use the ".*" notation. In the former case, it makes life easier to identify an external class, especially when you try to locate a buggy class or understand how the JSP page interacts with Java code. For instance, without the knowledge of the imported Java packages as shown below, a web developer will have to search through all these packages in order to locate a Customer class:

<%@ page import="com.mycorp.bank.savings.*" %> <%@ page import="com.thirdpartycorp.cashmanagement.*" %> <%@ page import="com.mycorp.bank.foreignexchange.*" %> ...

In the latter case, the written JSP page is neater but it is harder to locate classes. In general, if a JSP page has too many import directives, it is likely to contain too much Java code. A better choice would be to use more JSP tags (discussed later in this article).

Optional Tag Library Directive(s)

A tag library directive declares custom tag libraries used by the JSP page. A short directive is declared in a single line. Multiple tag library directives are stacked together in the same location within the JSP page's body:

<%@ taglib uri="URI1" prefix="tagPrefix1" %> <%@ taglib uri="URI2" prefix="tagPrefix2" %> ...

Just as with the page directive, if the length of a tag library directive exceeds the normal width of a JSP page (80 characters), the directive is broken into multiple lines:

<%@ taglib uri="URI2" prefix="tagPrefix2" %>

Only tag libraries that are being used in a page should be imported.

From JSP 1.2 Specification, it is highly recommended that the JSP Standard Tag Library (JSTL) be used in your web application to help reduce the need for JSP scriptlets in your pages. Pages that use JSTL are, in general, easier to read and maintain.

Optional JSP Declaration(s)

JSP declarations declare methods and variables owned by a JSP page. These methods and variables are no different from declarations in the Java programming language, and therefore the relevant code conventions should be followed. Declarations are preferred to be contained in a single <%! ... %> JSP declaration block, to centralize declarations within one area of the JSP page's body. Here is an example:

Disparate declaration blocks Preferred declaration block <%! private int hitCount; %> <%! private Date today; %> ... <%! public int getHitCount() { return hitCount; } %>
<%! private int hitCount; private Date today; public int getHitCount() { return hitCount; } %>
HTML and JSP Code

This section of a JSP page holds the HTML body of the JSP page and the JSP code, such JSP expressions, scriptlets, and JavaBeans instructions.

Tag Library Descriptor

A tag library descriptor (TLD) file must begin with a proper XML declaration and the correct DTD statement. For example, a JSP 1.2 TLD file must begin with:

This is immediately followed by a server-side style comment that lists the author(s), the date, the copyright, the identification information, and a short description about the library:

The rules and guidelines regarding the use of these elements are the same for those defined for JSP files/fragment files.

The rest of the file consists of the following, in the order they appear below:

Optional declaration of one tag library validator
Optional declaration of event listeners
Declaration of one or more available tags

It is recommended that you always add the following optional sub-elements for the elements in a TLD file. These sub-elements provide placeholders for tag designers to document the behavior and additional information of a TLD file, and disclose them to web component developers.

TLD Element JSP 1.2 Recommended
Sub-element JSP 1.1 Recommended
Sub-element attribute (JSP 1.2) description init-param (JSP 1.2) description tag display-name, description, example name, info taglib uri, display-name, description uri, info validator (JSP 1.2) description variable (JSP 1.2) description Indentation

Indentations should be filled with space characters. Tab characters cause different interpretation in the spacing of characters in different editors and should not be used for indentation inside a JSP page. Unless restricted by particular integrated development environment (IDE) tools, a unit of indentation corresponds to 4 space characters. Here is an example:

A continuation indentation aligns subsequent lines of a block with an appropriate point in the previous line. The continuation indentation is in multiple units of the normal indentation (multiple lots of 4 space characters):

<%@ page attribute1="value1" attribute2="value2" ... attributeN="valueN" %>
Indentation of Scripting Elements

When a JSP scripting element (such as declaration, scriptlet, expression) does not fit on a single line, the adopted indentation conventions of the scripting language apply to the body of the element. The body begins from the same line for the opening symbol of the element <%=, and from a new line for the opening symbol <%=. The body is then terminated by an enclosing symbol of the element (%>) on a separate line. For example:

<%= (Calendar.getInstance().get(Calendar.DAY_OF_WEEK) =Calendar.SUNDAY) ? "Sleep in" : "Go to work" %>

The lines within the body not containing the opening and the enclosing symbols are preceded with one unit of normal indentation (shown as in the previous example) to make the body distinctively identifiable from the rest of the JSP page.

Compound Indentation with JSP, HTML and Java

Compound indentation, for JSP elements intermingled with Java scripting code and template text (HTML), is necessary to reduce the effort of comprehending a JSP source file. This is because the conventional normal indentation might make seeing the JSP source file difficult. As a general rule, apply an extra unit of normal indentation to every element introduced within another one. Note that this alters the indentations of the final output produced for the client side to render for display. The additional indentations, however, are usually ignored (by the browser) and have no effect on the rendered output on the browser. For instance, adding more space characters before a

tag does not change the position of a table. So, applying this convention for indentation makes this looks nicer:

<% if ( tableHeaderRequired ) { %> <% } %>

Last Name	First Name

than this:

<% if ( tableHeaderRequired ) { %> <% } %>

Last Name	First Name

Comments

Comments are used sparingly to describe additional information or purposes of the surrounding code. Here we look at two types for JSP files: JSP and client-side comments.

JSP Comments

JSP comments (also called server-side comments) are visible only on the server side (that is, not propagated to the client side). Pure JSP comments are preferred over JSP comments with scripting language comments, as the former is less dependent on the underlying scripting language, and will be easier to evolve into JSP 2.0-style pages. The following table illustrates this:

Line JSP scriptlet with scripting language comment Pure JSP comment single <% /** ... */ %> <% /* ... */ %> <% // ... %> <%-- ... --%> multiple <% /* * ... * */ %>
<%-- - ... - -- %>
<% // // ... // %>
Client-Side Comments

Client-side comments () can be used to annotate the responses sent to the client with additional information about the responses. They should not contain information about the behavior and internal structure of the server application or the code to generate the responses.

The use of client-side comments is generally discouraged, as a client / user does not need or read these kinds of comments directly in order to interpret the received responses. An exception is for authenticity and legality purposes such as the identification and copyright information as described above. Another exception is for HTML authors to use a small amount of HTML comments to embody the guidelines of the HTML document structures. For example:

... ... ... ...
Multiline Comment Block

A multiline comment block, be it JSP or client-side, is decorated with the dash character "-". In the XML specification, the double-dash string "--" is not allowed within an XML comment block. Thus, for compatibility and consistency with this specification, no double-dash string is used to decorate comment lines within a multiline comment block. The following table illustrates this preference using a client-side comment block:

Preferred Non-XML compliant

JSP Declarations

As per the Java code convention, declarations of variables of the same types should be on separate lines:

Not recommended Recommended <%! private int x, y; %> <%! private int x; %> <%! private int y; %>

JavaBeans components should not be declared and instantiated using JSP declarations but instead should use the action tag.

In general, JSP declarations for variables are discouraged as they lead to the use of the scripting language to weave business logic and Java code into a JSP page which is designed for presentation purposes, and because of the overhead of managing the scope of the variables.

JSP Scriptlets

Where possible, avoid JSP scriptlets whenever tag libraries provide equivalent functionality. This makes pages easier to read and maintain, helps to separate business logic from presentation logic, and will make your pages easier to evolve into JSP 2.0-style pages (JSP 2.0 Specification supports but deemphasizes the use of scriptlets). In the following examples, for each data type representation of the customers, a different scriptlet must be written:

customers as an array of Customers

<% for ( int i=0; i <% } %>

<%= customers[i].getLastName() %>

<%= customers[i].getFirstName() %>

customers as an Enumeration

<% for ( Enumeration e = customers.elements(); e.hasMoreElements(); ) { Customer customer = (Customer)e.nextElement(); %> <% } %>

<%= customer.getLastName() %>

<%= customer.getFirstName() %>

However, if a common tag library is used, there is a higher flexibility in using different types of customers. For instance, in the JSP Standard Tag Library, the following segment of JSP code will support both array and Enumeration representations of customers:

In the spirit of adopting the model-view-controller (MVC) design pattern to reduce coupling between the presentation tier from the business logic, JSP scriptlets should not be used for writing business logic. Rather, JSP scriptlets are used if necessary to transform data (also called "value objects") returned from processing the client's requests into a proper client-ready format. Even then, this would be better done with a front controller servlet or a custom tag. For example, the following code fetches the names of customers from the database directly and displays them to a client:

<% // NOT RECOMMENDED TO BE DONE AS A SCRIPTLET! Connection conn = null; try { // Get connection InitialContext ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("customerDS"); conn = ds.getConnection(); // Get customer names Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT name FROM customer"); // Display names while ( rs.next() ) { out.println( rs.getString("name") + "
"); } } catch (SQLException e) { out.println("Could not retrieve customer names:" + e); } finally { if ( conn != null ) conn.close(); } %>

The following segment of JSP code is better as it delegates the interaction with the database to the custom tag myTags:dataSource which encapsulates and hides the dependency of the database code in its implementation:

result is a scripting variable introduced by the custom tag myTags:dataSource to hold the result of retrieving the names of the customers from the customer database. The JSP code can also be enhanced to generate different kinds of outputs (HTML, XML, WML) based on client needs dynamically, without impacting the backend code (for the dataSource tag). A better option is to delegate this to a front controller servlet which performs the data retrieval and provide the results to the JSP page through a request-scoped attribute. See the Enterprise section of Java BluePrints for an example.

In summary:

JSP scriptlets should ideally be non-existent in the JSP page so that the JSP page is independent of the scripting language, and business logic implementation within the JSP page is avoided.
If not possible, use value objects (JavaBeans components) for carrying information to and from the server side, and use JSP scriptlets for transforming value objects to client outputs.
Use custom tags (tag handlers) whenever available for processing information on the server side.

JSP Expressions

JSP Expressions should be used just as sparingly as JSP Scriptlets. To illustrate this, let's look as the following three examples which accomplish equivalent tasks:

Example 1 (with explicit Java code):

<%= myBean.getName() %>

Example 2 (with JSP tag):

Example 3 (with JSTL tag):

Example 1 assumes that a scripting variable called myBean is declared. The other two examples assume that myBean is a scoped attribute that can be found using PageContext.findAttribute(). The second example also assumes that myBean was introduced to the page using .

Of the three examples, the JSTL tag example is preferred. It is almost as short as the JSP expression, it is just as easy to read and easier to maintain, and it does not rely on Java scriptlets (which would require the web developer to be familiar with the language and the API calls). Furthermore, it makes the page easier to evolve into JSP 2.0-style programming, where the equivalent can be accomplished by simply typing ${myBean.name} in template text. Whichever choice is adopted, it should be agreed on amongst web developers and consistent across all produced JSP pages in the same project. It should be noted that the JSTL example is actually slightly different in that it gets the value of myBean from the page context instead of from a local Java scripting variable.

Finally, JSP expressions have preference over equivalent JSP scriptlets which rely on the syntax of the underlying scripting language. For instance,

<%= x %>

is preferred over

<% out.print( x ); %> White Space

White space further enhances indentation by beautifying the JSP code to reduce comprehension and maintenance effort. In particular, blank lines and spaces should be inserted at various locations in a JSP file where necessary.

Blank Lines

Blank lines are used sparingly to improve the legibility of ~~the~~a JSP page, provided that they do not produce unwanted effects on the outputs. For the example below, a blank line inserted between two JSP expressions inside an HTML

block call causes an extra line inserted in the HTML output to be visible in the client's browser. However, if the blank line is not inside a block, the effect is not visible in the browser's output.
JSP statements HTML output to client <%= customer.getFirstName() %> <%= customer.getLastName() %>
Joe Block <%= customer.getFirstName() %> <%= customer.getLastName() %>

Joe Block <%= customer.getFirstName() %> <%= customer.getLastName() %> Joe Block Blank Spaces A white space character (shown as ) should be inserted between a JSP tag and its body. For instance, the following
<%= customer.getName() %> is preferred over
<%=customer.getName()%> There should also be space characters separating JSP comment tags and comments:
<%-- - a multi-line comment broken into pieces, each of which - occupying a single line. --%> <%-- a short comment --%>
Naming Conventions Applying naming conventions makes your web component elements easier to identify, classify and coordinate in projects. In this section, we will look at these conventions specific to JSP technology.
JSP Names A JSP (file) name should always begin with a lower-case letter. The name may consist of multiple words, in which case the words are placed immediately adjacent and each word commences with an upper-case letter. A JSP name can be just a simple noun or a short sentence. A verb-only JSP name should be avoided, as it does not convey sufficient information to developers. For example:
perform.jsp is not as clear as
performLogin.jsp In the case of a verb being part of a JSP name, the present tense form should be used, since an action by way of backend processing is implied:
showAccountDetails.jsp is preferred over
showingAccountDetails.jsp Tag Names The naming conventions for tag handlers and associated classes are shown below:
Description Class Name XXX tag extra info (extending from javax.servlet.jsp.tagext.TagExtraInfo) XXXTEI XXX tag library validator (extending from javax.servlet.jsp.tagext.TagLibraryValidator) XXXTLV XXX tag handler interface (extending from javax.servlet.jsp.tagext.Tag/IterationTag/BodyTag) XXXTag XXX tag handler implementation XXXTag In addition, tag names must not violate the naming conventions of class and interface as specified in the relevant code convention for Java technology.
To further distinguish a tag-relevant class from other classes, a package suffix, tags, or taglib can be applied to the package name of the class. For example:
com.mycorp.myapp.tags.XXXTag Tag Prefix Names A tag prefix should be a short yet meaningful noun in title case, and the first character in lower-case. A tag prefix should not contain non-alphabetic characters. Here are some examples:
Example OK? mytaglib no myTagLib yes MyTagLib no MyTagLib1 no My_Tag_Lib no My$Tag$Lib no JSP Pages in XML Syntax JSP provides two distinct syntaxes: a "standard syntax" for writing JSP pages and an "XML syntax" for writing JSP pages as an XML document. JSP pages that are written using the standard syntax are referred to as "JSP pages." JSP pages that are written using the XML syntax are referred to as "JSP documents". This article primarily addresses JSP pages, but many of the concepts can be applied to JSP documents as well. Use of JSP documents is expected to increase as XML becomes more prevalent, and to address this the JSP 2.0 specification will introduce a much friendlier XML syntax.
It should be noted that the XML syntax used to author JSP pages is distinct from and is often confused with the XML view of a JSP page. The page author uses either the standard or the XML syntax to author a JSP page. The container then translates the JSP page into its XML view, which is exposed to Tag Library Validators.
JSP Document Structure JSP documents have the following basic structure:
JSP Document ...
The first line is an optional XML Prolog that defines the page as an XML document. After the optional prolog comes the comments for the document. The element defines this as a JSP document and must appear as the root element. The jsp namespace must be imported, and all tag libraries must be imported using this root element. The version attribute is required and specifies which version of JSP Specification is being used. The actual content of the JSP document appears as subelements of the element. Standard XML indentation rules should be applied consistently across the document, using 4 spaces as a single indentation unit.
A JSP document must be a well-formed XML document, so some elements, such as <% %> must be replaced by their XML equivalent, such as . See the JSP Specification for details.
XML Comments The JSP Specification is unclear about whether XML-style comments are stripped on output, so to be safe if a comment is intended to reach the client, it should be enclosed in a node, as follows:
... ]]> ...
Java Code in JSP Documents When writing Java code inside declarations, scriptlets, and expressions, a CDATA element should be used only when necessary to ensure your code does not break the document structure.
... for( int level = 0; level < 3; level++ ) { Text" ]]> } ...
Unlike those in the standard syntax, XML indentation rules should be followed regardless of the contents of an element.
Programming Practices In general, avoid writing Java code (declarations, scriptlets and expressions) in your JSP pages, for the following reasons:
Syntax errors in Java code in a JSP page are not detected until the page is deployed. Syntax errors in tag libraries and servlets, on the other hand, are detected prior to deployment.
Java code in JSP pages is harder to debug.
Java code in JSP pages is harder to maintain, especially for page authors who may not be Java experts.
It is generally accepted practice not to mix complex business logic with presentation logic. JSP pages are primarily intended for presentation logic.
Code containing Java code, HTML and other scripting instructions can be hard to read.
The JSP 2.0 Specification is deemphasizing scriptlets in favor of a much simpler expression language. It will be easier to evolve your JSP pages to JSP 2.0-style programming if Java code is not used in your pages.
See the Enterprise section of Java BluePrints for more guidelines and details.
JavaBeans Component Initialization JSP technology provides a convenient element to initialize all PropertyDescriptor-identified properties of a JavaBeans component. For instance:
However, this should be used with caution. First, if the bean has a property, say, amount, and there is no such parameter (amount) in the current ServletRequest object or the parameter value is "", nothing is done: the JSP page does not even use null to set that particular property of the bean. So, whatever value is already assigned to amount in the bankClient bean is unaffected. Second, non-elementary properties that do not have PropertyEditors defined may not be implicitly initialized from a String value of the ServletRequest object and explicit conversion may be needed. Third, malicious users can add additional request parameters and set unintended properties of the bean, if the application is not carefully designed.
If you still prefer to use property="*" in the jsp:setProperty tag for the purpose of producing neater code, then we recommend that you add a comment preceding the jsp:setProperty tag about parameters expected to be present in the ServletRequest object to initialize the bean. So, in the following example, from the comment we know that both firstName and lastName are required to initialize the bankClient bean:
<%-- - requires firstName and lastName from the ServletRequest --%> JSP Implicit Objects Direct use of JSP implicit objects to gain references to these objects rather than API calls is preferred. So, instead of using
getServletConfig().getServletContext().getInitParameter("param") to access the initialization parameter as provided by the ServletContext instance, one can make use of the readily available implicit object:
application.getInitParameter("param") In the case that only the value of an initialization parameter is outputted, it would be even better to use a JSTL tag to access the initialization parameter:
Quoting The uniform use of quoting is adopted. Quotations should be bound by two double-quote characters " instead of two apostrophe characters ' .
Non-uniform quoting Preferred quoting <%@ page import='javabeans.*'%>
<%@ page import="java.util.*" %>
<%@ page import="javabeans.*" %>
<%@ page import="java.util.*" %>
An exception is when apostrophes are needed, for example when double-quote characters are required within the scripting language:
Using Custom Tags If a custom tag does not have a body content, the content should be declared explicitly with empty (rather than defaulting to the word "JSP") like this in the tag library descriptor:
hello com.mycorp.util.taglib.HelloTagSupport empty ...
This tells the JSP container that the body content must be empty rather than containing any JSP syntax to be parsed. The effect is to eliminate unnecessarily allocation of resources for parsing of empty body contents.
Empty tags should be in short XML elements, rather than using opening-closing XML element pairs to improve readability. So,
is preferred over
Use of TagExtraInfo and TagLibraryValidator Sometimes, the valid ways to use a tag library cannot be expressed using the TLD alone. Then, a TagExtraInfo class or a TagLibraryValidator class should be written and registered in the TLD so that errors in tag library can be caught at translation time.
Use of JavaScript Technology JavaScript technology should be independent of particular features of browser types in order for the scripts to run properly.
Where it makes sense, it is a good idea to keep JavaScript code in individual files separate from JSP bodies, and use a statement like the following to import the JavaScript code into the JSP bodies:

BeanSoft 2007-05-09 15:34 发表评论

判断事件是不是发生在某组件中的 JS 函数

BeanSoft — Tue, 24 Apr 2007 08:56:00 GMT

摘要: 在实现某些功能, 例如只在某 DIV 上面弹出右键菜单的时候, 这个函数可以用一下(忘了从哪里看到以及改造的..抱歉), 仅供参考用, 用一些 JS 组件库应该可以更方便的实现阅读全文

BeanSoft 2007-04-24 16:56 发表评论

视频:使用 Netbeans 5.5可视化开发 JSF 的简单注册流程

BeanSoft — Tue, 24 Apr 2007 02:39:00 GMT

摘要: 影片时间: 05:32, 实际操作时间: 约 2 分钟阅读全文

BeanSoft 2007-04-24 10:39 发表评论

善用 Google: JavaScript 复制对象

BeanSoft — Tue, 27 Mar 2007 07:20:00 GMT

飛雪(leo)(***) 15:07:42
贏在執行(leo)(***) 15:05:48

1
1
123
1
123
1

我把这个转　成一个对象，
贏在執行(leo)(***) 15:07:52
比如：我现在有两个Ｖar 变量，a,b等。
比如：a有以下字段：
babs，bfuelelecset，scareconomyrange，scaricno，scarid，scarlevel
b：有以下字段：
babs，bfuelelecset，scareconomyrange，scaricno，scarid，name,keyno
我现在要把b的字与Ａ的字段一样的，将其值ＣＯＰＹ到Ａ中要怎么做
BeanSoft(***) 15:08:16
Java 还是脚本?
BeanSoft(***) 15:08:26
Java可以用 clone()
飛雪(leo)(***) 15:08:35
ＪＳ
BeanSoft(***) 15:08:36
脚本貌似也有类似的机制
飛雪(leo)(***) 15:08:50
？
$$简单爱-莹() 15:08:55
怎么好象XML 那是JS啊
BeanSoft(***) 15:08:59
for in 循环可以遍历所有属性
飛雪(leo)(***) 15:09:20
recToRec:function(oldRec,newRec)
{
var typename;
if(typeof oldRec=="undefined"||typeof oldRec=="undefined")
return oldRec;
for (var p in oldRec)
{
typename=typeof(newRec[p]);
if("object"==typename)
{
if (newRec)
}
}
}
飛雪(leo)(***) 15:09:26
我只有写到这里，
飛雪(leo)(***) 15:09:31
接下去不知道怎么写
飛雪(leo)(***) 15:09:46
typename=typeof(newRec[p]);
if("object"==typename)
这个是错的，只能得到值　
飛雪(leo)(***) 15:10:47
BeanSoft等兄弟们，出来帮忙一下
BeanSoft(***) 15:12:48
JavaScript 复制对象
BeanSoft(***) 15:12:54
Google 搜索, 有结果..
飛雪(leo)(***) 15:13:29
好的，谢谢　
BeanSoft(***) 15:13:54
第一个就是,带代码的..呵呵,其实你大部分时候去找 Google 就有答案

BeanSoft 2007-03-27 15:20 发表评论

一个带 checkbox 的 JS 树组件

BeanSoft — Mon, 26 Mar 2007 02:55:00 GMT

基于 AJAX Java 群的集体讨论

1. 用 http://www.java2s.com/Code/JavaScript/GUI-Components/Checkboxtreenodecheckeduncheckedgetthecheckeditems.htm

2. 用 YUI(Yahoo UI Library)

感谢: 一再咖啡屋的鼠标 Amigo

BeanSoft 2007-03-26 10:55 发表评论

AJAX 的小问题: 为啥是 Msxml2.XMLHTTP, 不能改变名字嘛?

BeanSoft — Tue, 20 Mar 2007 06:02:00 GMT

摘要: 今天有人询问,这个问题很典型,我刚学的时候也遇到过,仅仅代表个人理解. 阅读全文

BeanSoft 2007-03-20 14:02 发表评论

在线视频(英文):Professional Ajax Development with the Spring Framework

BeanSoft — Fri, 16 Mar 2007 10:10:00 GMT

摘要: http://event.on24.com/eventRegistration/EventLobbyServlet?target=lobby.jsp&eventid=32366&sessionid=1&key=B52EF34435CF9AE046E200229B9B685A&eventuserid=9915510 演讲英文: Male Speaker:... 阅读全文

BeanSoft 2007-03-16 18:10 发表评论

MapEasy 的北京地图 demo(本机运行)

BeanSoft — Tue, 06 Feb 2007 06:41:00 GMT

摘要: mapapi0.4alpha_beijing_demo.zip 1131KB 下载后本机运行, 只有一级缩放. 图片切片大小: 500x500 每片阅读全文

BeanSoft 2007-02-06 14:41 发表评论

表格拖动, 排序, 固定表头3合一的纯 JS 表格组件

BeanSoft — Sat, 03 Feb 2007 09:47:00 GMT

今天看到了这位朋友的文章: 表格拖动（改进加原创） , 写的很不错, 试了一下无法在 FireFox 下运行, 想起来已经是 Google 雇员的 Emil A Eklund 好像已经写过了一个使用非常简单的类似组件, 兼容 IE 和 FireFox, 找到了它, 给大家推荐一下:

http://webfx.eae.net/dhtml/collist/columnlist.html

在线演示:

Demo

这些英文写的很浅显, 随便看看用起来就 OK 了.

还看到同志们关于 Firefox 中没有定义 event 对象讨论的热火朝天, 但是 Emil 兄弟早就做了一些这方面的工作, 我需要的就是拿来用, 请浏览:

http://webfx.eae.net/dhtml/ieemu/ FF 下的 IE API 模拟.

Introduction

When it comes to DHTML Mozilla might be less powerful than IE4 but when it comes to JavaScript it just kicks ass. The first time a saw a setter being used with a prototype of the built-in HTMLElement constructor I was just blown away. One of my first thought at that time was that this was exactly what I needed to start emulating the IE DHTML Object Model for Mozilla.

The goal of this article is to emulate a lot of IE behaviors to work in Mozilla, both to make old IE specific scripts work in Mozilla but also to make it easier to create new scripts that work in both IE5 and Mozilla. The article is actually going to be a series of smaller articles, each one concentrating on a small part of the emulation.

BeanSoft 2007-02-03 17:47 发表评论

JSP 文件下载的相对完整代码(解决中文问题和Weblogic报错)

BeanSoft — Thu, 01 Feb 2007 07:42:00 GMT

摘要: 阅读全文

BeanSoft 2007-02-01 15:42 发表评论

AJAX IM - PHP 的 AJAX 聊天工具(可运行于Resin3下)

BeanSoft — Tue, 23 Jan 2007 12:24:00 GMT

摘要: ajaxim_v30.zip 297KB
国外的人用 PHP 编写的, 可以运行在 Resin 3 下. 官方站点: http://www.unwieldy.net/ajaxim/ . 这文件是原封不动下载下来的. 缺点: 不支持汉字和特殊字符的发送, 添加好友后第二次无法登录(也许是我 Resin 下跑的 bug?). 阅读全文

BeanSoft 2007-01-23 20:24 发表评论

一个基于文件的 Cache Filter(含源码)

BeanSoft — Tue, 23 Jan 2007 03:04:00 GMT

摘要: 这个过滤器可以预先将 JSP 文件解析的结果缓存到文件中, 这样第一次读取的时候需要 JSP 服务器的解析, 第二次以后就可以从文件读取了. 阅读全文

BeanSoft 2007-01-23 11:04 发表评论

JS日期选择器

BeanSoft — Thu, 18 Jan 2007 02:43:00 GMT

摘要: 这是2003年时候参加工作不久从网上找的一个东西, 用来提交表单的时候选择日期范围, 可以设置多个. 原作者未知, 我稍有改动, 就是加入了两个图片. 阅读全文

BeanSoft 2007-01-18 10:43 发表评论

Lightbox,灯笼?

BeanSoft — Mon, 15 Jan 2007 12:15:00 GMT

摘要: Lightbox,灯笼?

2007-01-15

其实这不算一个 AJAX 的内容, 不过原始站点的是: Lightbox JS v2.0 http://www.huddletogether.com/projects/lightbox2/ 详情您可以自己去看, 是加载图片的. 阅读全文

BeanSoft 2007-01-15 20:15 发表评论

推荐一个国内的AJAX Demo 站点: http://www.tangtang8.com/ahax/

BeanSoft — Fri, 05 Jan 2007 06:28:00 GMT

例子比较实用, 文件也比较小, 虽然后台是 PHP 的, 但是比较易懂, 便于修改.

常用DEMO

原AHAX改名为BINGO，相关内容也有局部调整，请下载最新的版本，另外AJAXCALL和AJAXFORM两个函授全部改为大写，请注意！

AJAXCALL

测试一是用GET请求并返回一个HTML文档(当前时间)

测试二是用POST请求并返回一个XML，并获取TAG RETCODE的值(-200)

语法：AJAXCALL(url,handleResponse,param); 将url返回的数据交给handleResponse(doc)处理
参数：url：请求的地址；handleResponse：回调函数，doc 为AJAX返回的文档；param：附加参数（isCache：是否需要缓存，默认不缓存；isXML：是否返回XML文档，默认HTML；method：发送方式，默认GET）
例子：
AJAXCALL("gaogao.xml","yoyo2","method=POST ,isXML=true ,isCache=false");
AJAXCALLl("getnews?pid=23412","shownews");
备注：
如果POST数据，请将数据编码后加在URL后，例如：
AJAXCALL("gaogao.php?name="+$U('哟哟')+"&sex="+$U('male'),"yoyo2","method=POST")

AJAXFORM

语法：AJAXFORM(formID,handleResponse,param); 将表单数据用AJAX POST出去
参数： formID：表单的ID；handleResponse：回调函数，doc 为AJAX返回文档；param：附加参数（isXML：是否返回XML文档，默认HTML；与AjaxCall不同，AJAXForm只有isXML一个附加参数）
例子：

附加功能

$('div') 等同于 document.getElementById('div')

$F('div') 等同于 document.getElementById('div').value

getTagValue(XMLDoc ,Tag ) 获取XML文档指定TAG的第一次出现的值

$U(str) 等同于encodeURIComponent(escape(str)

BeanSoft 2007-01-05 14:28 发表评论