为什么规范的页面不要用import语句？今天有个例子

<%@page import="xxx.xxx.common.XMLManager"%>

之前一直都坚持保持“干净的”jsp页面，也因此一直没遇到什么问题，所以也就不明白这样坚持的好处在哪里。

在新公司维护旧的项目，这里的jsp页面有大量的import，所以今天就碰到了问题。

重构的时候，感觉XMLManager放的package位置不太贴切，就用eclipse的refactor功能把这个类move到一个更合适的位置。因为知道eclipse会自动把依赖的类都进行相应修改，很放心地就提交了。结果过一会发现很多jsp页面各种异常。

一查就发现原因很简单，就是因为这些页面import了我刚刚移动的这个类，refactor功能是无法自动关联修改jsp页面的，所以要么自己把jsp页面都手动改了，要么就老老实实把类放回去。安全起见，我还是把XMLManager类又放回了原来的package。

重构失败了，不过也就知道了为什么规范的jsp页面应该尽量少用import语句。包括尽量不用java脚本，也是这个原因——维护困难。

评论

14 楼 kyfxbl 2010-12-31  

确实是我忘记了。但是如果jsp里没有import java类，就不存在忘记不忘记了，呵呵。

你的步骤是可行的，但看了就感觉工作量很大。

13 楼 skzr.org 2010-12-30  

kyfxbl 写道

skzr.org 写道

其实jsp中不写import，那jsp调用java怎么办？

个人特别反对使用标签：这东西看着恶心。
如果在标签和模板解析中选择，重复性高的我会选择模板解析，如果重复性低的我就直接写个帮助类，做这个事情。

至于jsp的验证，使用MyEclipse的validate就可以检测出来问题的

重构的时候需要注意所有可能的影响，我一般先search file，考察影响范围，再考虑怎样重构

记得一个项目，原来没有考虑系统皮肤的问题，后来要考虑，一个search，基本上所有的
jsp，js和css里面都有需要更改的，最后设计一个search and replace的步骤，最终都改好了，几千个文件的修改，修改+测试用了3天！

我觉得你的案例已经说明了jsp和java耦合带来的问题，一次改几千个文件，这完全是维护噩梦嘛。

jsp不应该去调用java，页面中需要的值直接从action中传出来，或者在session里获取比较好一点。

用标签是最好的，不知道为什么你觉得恶心？难道你觉得一个自定义标签恶心，十几行甚至几十行java脚本反而不恶心？

换肤例子实际上是说明，重构的一般步骤，其实未涉及到标签、java和jsp：
1 确定范围：找到所有受到影响的地方： java,jsp等等一切相关资源文件，一般通过eclipse的search file，可以标识出来
2 确定实施方案：根据影响的范围，寻找合理的重构实施步骤
3 动手修改
4 验证此次修改

你的例子说的重构时发现jsp中的java代码未一起变动，只是重构时忘记 确定此次重构的影响范围而已
jsp标签感觉用处不大，我们的UI组件基本不会变化，因为从一个成熟的UI切换到其他的UI，还要重新学习，遇到问题还要重新解决，麻烦，就如领导要求的这个chart，要用标签，万一我门不用jfreechart，用flash chart呢？其实说不定此软件都消亡了，还没有遇到需要切换的时候

12 楼 wpfwupengfeiwpf 2010-12-28  

kyfxbl 写道

skzr.org 写道

其实jsp中不写import，那jsp调用java怎么办？

个人特别反对使用标签：这东西看着恶心。
如果在标签和模板解析中选择，重复性高的我会选择模板解析，如果重复性低的我就直接写个帮助类，做这个事情。

至于jsp的验证，使用MyEclipse的validate就可以检测出来问题的

重构的时候需要注意所有可能的影响，我一般先search file，考察影响范围，再考虑怎样重构

记得一个项目，原来没有考虑系统皮肤的问题，后来要考虑，一个search，基本上所有的
jsp，js和css里面都有需要更改的，最后设计一个search and replace的步骤，最终都改好了，几千个文件的修改，修改+测试用了3天！

我觉得你的案例已经说明了jsp和java耦合带来的问题，一次改几千个文件，这完全是维护噩梦嘛。

jsp不应该去调用java，页面中需要的值直接从action中传出来，或者在session里获取比较好一点。

用标签是最好的，不知道为什么你觉得恶心？难道你觉得一个自定义标签恶心，十几行甚至几十行java脚本反而不恶心？

也应该分情况而定吧,很多自定义标签和大量的值充斥到session,难道不影响性能么?

11 楼 kyfxbl 2010-12-28  

skzr.org 写道

其实jsp中不写import，那jsp调用java怎么办？

个人特别反对使用标签：这东西看着恶心。
如果在标签和模板解析中选择，重复性高的我会选择模板解析，如果重复性低的我就直接写个帮助类，做这个事情。

至于jsp的验证，使用MyEclipse的validate就可以检测出来问题的

重构的时候需要注意所有可能的影响，我一般先search file，考察影响范围，再考虑怎样重构

记得一个项目，原来没有考虑系统皮肤的问题，后来要考虑，一个search，基本上所有的
jsp，js和css里面都有需要更改的，最后设计一个search and replace的步骤，最终都改好了，几千个文件的修改，修改+测试用了3天！

我觉得你的案例已经说明了jsp和java耦合带来的问题，一次改几千个文件，这完全是维护噩梦嘛。

jsp不应该去调用java，页面中需要的值直接从action中传出来，或者在session里获取比较好一点。

用标签是最好的，不知道为什么你觉得恶心？难道你觉得一个自定义标签恶心，十几行甚至几十行java脚本反而不恶心？

10 楼 skzr.org 2010-12-28  

其实jsp中不写import，那jsp调用java怎么办？

个人特别反对使用标签：这东西看着恶心。
如果在标签和模板解析中选择，重复性高的我会选择模板解析，如果重复性低的我就直接写个帮助类，做这个事情。

至于jsp的验证，使用MyEclipse的validate就可以检测出来问题的

重构的时候需要注意所有可能的影响，我一般先search file，考察影响范围，再考虑怎样重构

记得一个项目，原来没有考虑系统皮肤的问题，后来要考虑，一个search，基本上所有的
jsp，js和css里面都有需要更改的，最后设计一个search and replace的步骤，最终都改好了，几千个文件的修改，修改+测试用了3天！

9 楼 白糖_ 2010-12-28  

这算不算MVC的原则呢，让展示层与后台代码分离

8 楼 helin 2010-12-27  

重构的时候选上页面，包括jsp,xml，这样就安全了。

7 楼 yunchow 2010-12-27  

mp_juan 写道

对于静态和常量数据，建议自己实现一个ContextLoaderListener，把所有的静态资源，常量加入到ServletContext中去，这样不就解决问题了？也可以自己实现标签，解析你的数据，这样页面不需要引入任何java类，包括常量。

小项目倒是可以,我有时也这么做的,但是大项目中,特别是在集群环境当中,如果太多其实也造成一定程度上的负担

6 楼 mp_juan 2010-12-27  

对于静态和常量数据，建议自己实现一个ContextLoaderListener，把所有的静态资源，常量加入到ServletContext中去，这样不就解决问题了？也可以自己实现标签，解析你的数据，这样页面不需要引入任何java类，包括常量。

5 楼 yunchow 2010-12-27  

jsp 也好重构啊, 如果用的是eclipse,直接ctrl+H, 如果不是,写个脚本搞定

4 楼 kyfxbl 2010-12-27  

leepengyu 写道

这是一个理想……
实际中要做到很难。

新项目的话，不难。重构已经比较庞大的旧项目，确实比较难。

3 楼 leepengyu 2010-12-27  

这是一个理想……
实际中要做到很难。

2 楼 hastune 2010-12-27  

jsp引入包0 0写java代码吗.

用标签神马的不是来得更爽吗

1 楼 davepkxxx 2010-12-24  

看吧，调用一些静态数据，枚举的话我还是会引用的