静态化？我没听错吧？

进到公司后无所事事了几天，便接到任务准备制作公司自己的网站。应该是考察newbie的吧，赫赫

花了几天做了一个AJAX的前台，功能全实现了，只是考虑到后来的人升级起来也许会有困难（你该不会要求一位德高望重的J2EE开发人员去精通Javascript这种小东西吧？），所以和组长提议还是不做了；后来又考察了一下Portals->Jetspeed 1" href="http://portals.apache.org/jetspeed-1/" target="_blank">Jetspeed-1，虽然吧，我只浅薄地接触过它，Portals->Jetspeed 1" href="http://portals.apache.org/jetspeed-1/" target="_blank">Jetspeed-1貌似还不能直接支持实现JSR-168的portlet，而且短时间内我还无法精通portal这样博大的东西，但是JSR-168和Rickard Oberg那 Request for feedback: why portlets?" href="http://jroller.com/page/rickard?entry=request_for_feedback_why_portlets" target="_blank">highly biased于portal和portlet的态度，还有蓄势待发的Portals->Jetspeed-2" href="http://portals.apache.org/jetspeed-2/" target="_blank">Jetspeed-2（虽然动静并不大…），都让我没有理由不认为这东西不是一个好的解决方案。

最终敲定的方案让我很分特：根据数据生成静态化页面…

这项技术无可厚非，不过在我看来拿Java去做这么一项任务完全是亮相Java的短处。

• 配 置问题。想生成一个不依赖app server而可以随处可用的静态站的话，将有可能不得不使用到大量配置，当然用相对路径就能够解决有关页面上的图像、链接、css、js等等的定位问 题，不过想做一些其他个性化的设置的话，配置还是不能省的，比如网站名、公司名等等。这些拿php做起来太方便不过了，不过拿Java做起来呢？无非就几 种方法：写文件——或properties或xml或plain text；数据库访问——用不用ORM视BT程度；AppContext内可访问的对象——或静态或受控实例或singleton或与JNDI名绑定。怎 么样做都怎一个烦字了得。当然配置问题是每个Java程序都要面对的事情，否则Jakarta->Commons->Configuration" href="http://jakarta.apache.org/commons/configuration/" target="_blank">Commons-Configuration还 是关门删掉repository算了，但是怎么管理这些配置确实值得商榷：真的需要一个全局范围内的配置么？有时我宁可做一些局部性的配置，就像把一个大 的配置文件打碎成若干个小的配置文件，虽然数量多了显得零碎，但是每个文件所关注的事情都比较集中。这一点做spring应用的应该有体会，一个庞大的 applicationContextXXX.xml编辑起来不是那么顺手的，除了好的xml编辑器可以帮你检查local的引用名字是否正确以外，没有 其他别的好处了，所以很多人还是把关注于某一个方面的配置单独写到一个applicationContextYYY.xml里面，道理差不多。
• 发布问题。PHP和ASP 方面都有很多的程序提供静态页面生成的功能（这也是这个项目“灵感”的来源），但是我觉得得追究一下这么做的缘由：一般的虚拟主机为了平衡同一服务级别用 户的负载，都设置了CPU负载保护，负载稍微大一些就会无法访问，而静态的页面当然不可能占用主机多大的负载，所以才会这么做，当然一些访问量比较大的网 站为了减轻服务器的CPU负载也会这么做，但是针对于特定网站的解决方案可以依靠服务器环境做很多特殊的配置，这种情况跟我参与的这个项目不太一样。但 J2EE应用想生成静态页面的话就不好办了，生成出来的静态页面堆在应用的目录下的某个目录中，成了烫手的热山芋：这么些东西应该扔在哪儿啊？不用您好意 提醒我也大约知道有N种方法能够解决这个问题，但提醒我之前您要想一下，这些方法足够优雅么（如果确信够优雅，请reply，让我开开眼长长见识）？PHP和ASP 程序生成静态页面方便就方便在于负责静态页面输出的服务器和负责运行PHP、ASP程序的主机和web服务程序一般是同一个，所以指定好路径就可以了，而 J2EE应用就不一样了，一是有可能输出静态页面的服务器和app服务器是两个，或者是两个不同的daemon进程，比如大家都知道的 apache<-mod_jk/mod_jk2->tomcat这种做法，这种情况下生成出来的静态页面要放在哪里呢？不会还要指导我做文件 复制、移动的勾当吧，这不够优雅，因为你要获取与应用无关的一些设置，比如路径等等。或者您要指导我把apache的该站点的根目录指定到app生成的静 态页面所放置的目录——可行，确实可行，不过还是不够优雅，因为你还要过去改apache的配置。OMG，不要再告诉我去做配置了…或者您说，干脆都只用 appserver来做吧，让它既负责运行应用又负责输出静态页面，让该死的性能问题见鬼去吧——又是一个完全可行的方法，问题是，你的app的 context路径怎么办？我们都知道，一般的webapp部署时大多数情况下会被appserver分配一个context名，手动或自动，这样生成的 静态页面就都放在这个context对应的目录下面，另一个问题应运而生：难看的URL。以往打开firefox，地址栏内输入company然后 Ctrl+回车就到了这个company的网站，可现在呢，输入这个地址后发现我们被重定向到http: //www.company.com/cms/static/index.html，虽然重定向是自动完成的，下一次回来直接访问http: //www.company.com/即可，但是如果有人想引用这个网站上的某篇文章、某个图片等等，这个URL也许会长得不那么必要。而且，负责完成从 http://www.company.com/跳转到之后那个糟糕的URL的页面谁来做呢？用同样的app来生成么？然后手动或者自动复制/移动到这个 站点的根目录？优雅问题…
  对付不同服务器、服务daemon的路径问题我所能想到的自动一些的方法也只是通过FTP、WebDav之类的辅助途径解决了，这对目标主机都有一定的要求；手动方法就不说了，呵呵。
• 模 板问题。我建议用portal做这个站点考虑的就是首页和各个portlet的外观和布局等等都可以很容易地解决，但是项目进行的过程中，用户定制的灵活 性被重视起来——我不反对可灵活定制的东西，否则也不会喜欢Linux——但是定制化程度也要视用户而定是吧？定制化程度低，用户可能会觉得不个性，定制 化程度高他们又该嫌麻烦。所以我一直宁可降低可定制化程度——当然也视用户类型而定了，好的架构对付起定制化需求来说绰绰有余，大部分的定制化工作最后都 反应在表现层，所以对应用的核心架构影响不大。对于生成静态页面这种活儿，麻烦的就是模板了。我在以前一篇blog里也提过这么一个方法，然后后台就通过 一些规则拼接Jakarta->Velocity" href="http://jakarta.apache.org/velocity/" target="_blank">Velocity模 板里可能出现的变量名并给这些变量名挂上一个对象。灵活是灵活了，后果是出现了大量规则，比如变量命名的规则，模板命名的规则等等（当然，做个管理界面让 用户管理这些变量和规则也是没错的，不过…）。目前为止仍然是不够100%灵活——我的意思是，要么定制化程度很低，要么做到头。以前Gavin和我提过 他的一个朋友delphij说的话：“对于最终用户，我倾向于让他们使用智能设备，而不是PC”（大意是这样），很认同这句话，当然前提也是找准用户类 型，我估计你可能知道有些user连浏览器的“后退”按钮都不知道是干什么用的所以这个自定义模板机制究竟是帮助他们还是阻碍他们了，目前还不得而知，不过我是抱着悲观和消极的角度来看这个的——他们会觉得：麻烦。

就 这么项目本身的性质而言，静态化还会带来升级、扩展方面的麻烦，一是模板改起来不是玩的，二是有很多动态的页面，比如论坛等等，这些可没法静态化；再有就 是扩展性问题，静态之后几乎没法扩展。我一直认为，一个企业的网站，应该自觉地使自己区别于一个普通的CMS，因为企业网站完全可以当作自己销售链、服务 链等等中的一个环节，动态的webapp才有可能进行扩展，进而使之成为企业B2B、B2C活动的进行地点，市场人员也可以使用网站获得的一些数据等等来 为企业的市场计划做参考，这样这个网站也算没白做。难道堂堂一个IT企业的网站，还要像以前高喊“电子商务”口号的年代中某个卖咸菜的公司的网站一样，主 页上放个email链接就算建了个网站做了把电子商务了么？