JSP虚拟主机,jsp空间,java空间,java虚拟空间JSP虚拟主机,jsp空间,java空间,java虚拟空间

从Open Source项目中学习i18n 处理技巧 (java webapp)



作者:    文章来源:
发布日期:2007年04月02日
原文: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  
Copyright © 2002-2012 JSPCN.net. All rights reserved.
JSP中文网    备案号:粤ICP备09171188号
成都恒海科技发展有限公司    成都市一环路南二段6号新瑞楼三楼8号