|
|
原文：http://www.redsaga.com/mambo/content/view/25/2/
执笔： 曹晓钢
Sunday,2004年November月21日
记得以前看到过一个无厘头搞笑文：妓女和程序员都有一个共同特点，都需要不断学习，一个是看A片，一个是看程序....我们来看看几个开源软件的webapp的i18n处理,我们能学到些什么 :)
最简单的i18n,就是用一个resource bundle,然后去load不同的resource文件，根据用户的选择或者根据浏览器送来的locale判断出使用哪个bundle，找到对应的字符串呈现给你。
改进一下，可以实现对resource文件的监视，如果有了变化，自动reload,这样可以避免重新启动web app。
另一个改进是load多个不同的resource文件，这样就可以在项目中按照模块分工，对大项目很有用。
通常的显示采取jstl或者等效的tag来实现。
除了这种方法外，还有些什么方案呢? 记得以前看到过一个无厘头搞笑文：妓女和程序员都有一个共同特点，都需要不断学习，一个是看A片，一个是看程序....我们来看看几个开源软件的webapp的i18n处理,我们能学到些什么 :)
早先在看jbossnukes的时候,他的i18n是使用一个后置的servlet filter来实现的。在输出(不管是jsp还是什么)的时候,只需输出:${somePackage.someProperty} 这样的字符串,在送到客户端之前,会被末端的servlet filter拦截,把所有的${}都替换成相应的i18n字符串.
好处是显而易见的,由于不再有jstl tag,jsp生成的java将节省很多tag处理的代码,而且也便于在各种配置文件中使用i18n key,甚至可以把${xx}放在数据库字段中,反正最后输出的末端统一处理.也可以方便的进行resource key的组合输出.
前几天看mvnforum,又发现一个精彩的实现,和jbossnukes正好相反,mvnforum的i18n在系统的最前端进行,也就是预处理:假若有100个jsp文件,需要支持10种locale,则会生成10个不同的目录,每个都包含原先100个sjsp的拷贝，然后把jsp文件中的key替换,处理出整套专用的localized jsp来.
乍一看觉得这样很傻,仔细一想不由得佩服,这样做的目的就是在于提高速度,和jbossnukes的后置处理一样,它也消除了jsp文件转换成java文件是产生的繁琐的出入口代码,而且甚至不再需要任何后续处理! 其实原先jsp 容器的设计观念，就是由jsp容器本身来处理“预编译”的动作，把jsp变为java code。假若我们再对文件系统进行监视,然后每当resource文件有变化时,即时重新生成jsp,这样就可以在resource有更新的时候无需重启服务器，几乎就是i18n处理目前的最好方案了。 要特意说得cool一点的话，可以这么说：是对servlet的“预编译”(jsp)的再次“预编译”。
学习非解释型计算机语言的人一定会区分两个概念，那就是构建时(buildtime)和运行时(runtime)。但是动态编译的出现,使得这二者的区别日渐模糊,RTTI,reflection,dynamic proxy,直到byte code enhencement,再到高层的AOP概念,无一不是动态实现原先静态编译才能达到的程序动作。既然任何类都可以直接由byte code 生成器生成，在运行时就完全可以自我繁衍出另一个不存在的类，在不存在的生命周期中完成不存在的动作行为。hoho，matrix的雏形已经出来？ :P
|
|
