减少jsp文件目录的维护成本，需要一种什么样的JSP发布框架?

      载自：
     即使对于一个大部分基本逻辑都包装在标签/类/servlet/EJB中的网站，以至于在jsp(SUN企业级应用的首选)中看不到任何的javalet代码，随着规模的扩大和项目时间的延长，目录中总是堆满了越来越多的垃圾文件。有些文件本身不是垃圾，而是被包容的子文件，但是jsp(SUN企业级应用的首选)服务器可不管这个，如果不是jsp(SUN企业级应用的首选)后缀，它就会被jsp(SUN企业级应用的首选)把源代码下载到客户端；或者，同样是jsp(SUN企业级应用的首选)一样时就让维护者头大。如果不是采用良好的文件策略，那么随着规模的扩大，一般的中大型站点堆出几千上万的jsp(SUN企业级应用的首选)文件，其中每一个模块分上几十个，是非常正常的；这时侯，管理这些文件就成为一件艰苦的工作；事实上，如果不是多人分管的话，一个发布管理员真正能够维护的文件如果超出一百个，效率就会急剧降低。何况，还有更重要的sql文件，class文件，xml(标准化越来越近了)设置文件……。为什么总是努力使用bean/fragments/标签/ORclass（如EJB），这就是原因之一。事实上，从事过大型项目的开发员对于后期目录中那种不知那个有用那个无用但却要么不管要么只能一个个识别的经历，总是一种难言的痛苦。经历过这种痛苦也会对可重用组件在项目中实际上降低了后期维护费用的感受良深。
      要实现高度的重用性，减少需要维护的文件的数量，就需要对系统架构甚至前台框架都进行抽象，重用的方式除了Class等方式外，还可以使用shellscript帮助，特别是对那种必须分割出目录管理而实际上结构非常相似的类型。通过这个办法，即使是很大的项目，也可以把需要维护的jsp(SUN企业级应用的首选)文件，不含java类库压缩到一百个以下，包括用于包含的小jsp(SUN企业级应用的首选)片片fragments。
   良好的命名规则可以进一步提高对文件的识别，也便于使用shellscript按文件类型进行管理。为了防止被jsp(SUN企业级应用的首选)服务器下载到客户端，如果是与apache(Unix平台最流行的WEB服务器平台)结合的话，可以在apache(Unix平台最流行的WEB服务器平台)中建立禁止下载的文件类型。我一般是把这种文件命名为jsp(SUN企业级应用的首选)_，为了达到这种命名的规范性，甚至不惜把已经写好的程序改一遍，幸好，在良好的组织框架下，文件总是只有几十个，并且只需要改一两行的几个字母。尽管如此，每次都仍是让我感到生畏，这种规范工作的确是最不令人兴奋的。
   建立良好的命名规则和目录结构，也是为了可以有效重用已有工作的前提，但什么时侯应该达到重用呢？毕竟即使是很相似的框架类型，在面向重用要求时，就意味着很多的if-else。logic:equal/present之类，在Class中可以通过接口和继承实现代码的高效率，而在jsp(SUN企业级应用的首选)中，如果重用变型达到三个以上，大量的if-else之类就令混帐代码冗余广泛伸延，而在jsp(SUN企业级应用的首选)文件内部令维护难道大大增加一个档次；或者一个简单的要求就需要include十次八次，同样是加大了维护成本。（要知道，接手者，甚至是自已吧，过了几个月，对于开发中的印象早就消失干净了。）
   这是一个难以协调的问题，可以调整的空间很小：如果不重用而一个文件任务专用，意味着每次需求变动时要重复维护多个非常相近的文件；超过三个的话，也就等于说这个文件建立方式是低效的。而如果文件复用的话，依靠在jsp