|
随着portal的应用在中国越来越广泛，越来越受欢迎，Liferay在中国的用户数也随之增长。每个Liferay的开发人员都会面临一个问题，到底通过应用liferay的哪种方式进行开发是最好的呢？
我认为在Liferay上开发portal主要有两种方法： 第一种，利用Extension Environment形式进行开发，设置Extension Environment的方法网上已有很多，在这里不再做详细说明，大家可以参考官方的http://wiki.liferay.com/index.php/Setting_up_the_Extension_Environment，或者我们group里面的http://liferay.group.javaeye.com/group/blog/126024。 用该方式进行开发存在着以下问题： 1）和Liferay绑定得太紧，从version4.1到version4.2目录结构发生变化，从version4.2到version4.3底层程序实现发生变化。这样结果就是，我们升级存在着一定的风险，虽然官方提供了升级方案，但是随着数据的增长了，开发过程的不规范，升级带来的风险是无法估计的； 2）开发成本，Liferay用的是类似MDA模型的构架，但是过度使用设计模式和代码的复杂性，让开发成本不能保持在一个相对底的水平，更重要的是他的代码没有注释，学习起来比较费劲，这样的一个结果就是必须要有水平相对高的程序员去做这方面的研究，防止出异常后无法解决。 第二种，利用plugin的形式进行开发，plugin的概念liferay很早就已经有了，但是一直表现得不是很强，相对的例子也比较少。从Liferay4.3开始，plugin在这个portlet container上面有了非常强的体现，官方发布了专门开发plugin的SDK，hot deploy的bugs也比前几个版本减少了不少。Plugin支持java、php、ruby… 现在我们看看通过plugin开发portlet到底有哪些必需元素，以java的开发为例，liferay-plugin-package.properties和liferay-plugin-package.xml――对plugin的一个描述，包括需要下载的tld文件和jar文件；liferay-display.xml――portlet所属的category；portlet.xml和liferay-portlet.xml――这两个文件如果接触过liferay的人都不会陌生，就是对portlet的详细描述。这几个文件是必需的，liferay的就是通过解析这几个文件，通过listener来把你的应用以portlet的形式发布并加载到这个container里面。而portlet加载后，直接访问你的应用是通过portal-bridge进行的。 p.s. 4.3的版本plugin通过修改tomcat的classloader的机制，修改一些context的配置 - <Context>
- <Loader
- loaderClass="com.liferay.support.tomcat.loader.PortalClassLoader"
- />
- </Context>
<Context> <Loader loaderClass="com.liferay.support.tomcat.loader.PortalClassLoader" /> </Context> 让当前的war包能共享liferay war中的所有jar包，各自的应用只需要保留自己的jar包（在liferay中没有）就可以了。 开发plugin最简单的方法是用官方提供的SDK，直接运行ant命名或已经定义好的脚本，就可以生成相关的应用。 
例如，我要生成一个名为”hello world”的portlet，只需要在portlets下运行脚本：create hello-world “hello word”就会自动生成一个名为”hello world”的项目，必需的所有配置文件都已经自动的生成 
p.s.个人来说我并不喜欢他自动生成的目录结构，既然是用plugin的形式进行开发，那直接用自己喜欢的目录结构和开发方法，最后在加上这些配置文件就好了。 同样的方法，你可以开发theme，layouttpl等等 
Conclusion：Liferay是一个非常好的portlet container，由于文档的缺少，代码的复杂性，升级的频繁性等等问题，如果直接用Liferay进行二次开发，会带来不少的风险。所以个人的观点是把Liferay只看成是一个portlet container，作为一个建站工具，应用他的用户管理和权限管理的功能，然后通过plugin的形式，用你自己熟悉的方式进行开发，然后再发布到Liferay中，这样能把风险降到最低。
|
