问题 #5: 无用的出错信息 JSP常有一些令人惊讶的出错信息。这是因为页面首先被转换成为一个servlet然后才进行编译。好的JSP 工具可以相对增加找到出错位置的可能性,但即使是最好的工具也无法使所有出错信息都能容易地被读懂。由于转化的过程,一些错误对工具来说可能根本不可能被识别。 例如,假设JSP页面需要建立一个对所有页通用的标题。以下代码并没有错: <% static String title = "Global title"; %> 但Tomcat会提供以下出错信息: work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected. static int count = 0; ^ 此信息认为以上脚本被放入 _jspService()方法而静态变量不允许放入方法中。该语法应该是 <%! %>。页面设计者很难读懂这些出错信息。即使最好的平台在这方面也做得很不够。即使所有 Java代码都从页中移出也无法解决问题。另外,以下表达式有什么错? <% count %> tomcat给出: work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in type declaration. count ^ work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration. out.write("\r\n"); ^ 换句话说,只是遗失了一个标记而已。应该是 <%= count %>。 由于template engine可以在template文件中直接产生而没有任何戏剧性的向代码转化,所以可以非常容易地给出适当的出错报告。 依次类推,当c语言的命令被打入Unix shell的命令行, 你并不希望shell 会生成一个C程序来运行这个命令,而只是需要shell简单地解释命令并加以执行,如有错误也直接给出。 问题 #6: 需要一个编译器 JSP需要一个置放在webserver中的编译器。由于Sun拒绝放弃包含了他们的javac编译器的tools.jar库, 这其中就变得有问题了。Web服务器可以包含进一个第三方的编译器如ibm的 jikes。但这样的编译器并不能在所有平台上顺利工作(用 C++写成的) 也不利于建立纯Java 的web服务器。 JSP有一个预编译选项可以起到一定作用,尽管并不完美。 问题 #7: 空间的浪费 JSP消耗了额外的内存和硬盘空间。对服务器上每30K的JSP文件,必须要有相应的大于30K的类文件产生。实际上使得硬盘空间加倍。考虑到JSP文件随时可以很容易地通过 <%@ include>包含一个大的数据文件,这样的关注有着很现实的意义。同时,每一个JSP的类文件数据必须加载到服务器的内存中,这意味着服务器的内存必须永远地将整个JSP文档树保存下去。少数一些JVM有能力将类文件数据从内存中移去;但是,程序员通常无法控制这样的规则来重新申明,而且对大的站点来说重新申明可能不是很有效。对template engines由于没有产生第二个文件,所以节省了空间。Template engines还为程序员提供对templates在内存中进行缓存的完全控制。 |
正在阅读:困扰JSP的一些问题与解决方法困扰JSP的一些问题与解决方法
2004-04-02 10:19
出处:eNet硅谷动力
责任编辑:sdq
键盘也能翻页,试试“← →”键