为什么选用joomla!
1.易于使用,功能强大
“对于一个不会网络编程的新手,不知道HTTP、HTML、CSS、PHP、ASP等网络语言的用户,要做一个网站简直就是一个不可能的任务!Joomla!系统使这个不可能的任务变得“可能”,而且会让建站旅程变得愉快起来!”
-----------摘自《joomla! 建站步步通》
2.技术支持强大,开发人员众多
“团结就是力量”,Joomla!也是因为支持者众多而力量强大。Joomla!核心支持小组成员约有150人,包含了开发者、设计者、系统管理者、文件撰写者,还有超过20万名的参与会员。
-----------摘自《joomla! 建站步步通》
3.技术先进
应用了非常多的的新技术,如seo,缓存支持,memcache,file.....,先进的框架设计,支持插件机制,模块,等等。
4.很多成熟的第三方扩展应用,连外观设计都可以用模板形式来搞定。
来自全球开源或商业公司的成千上万种不同网站应用的扩展套件,强大的安装机制,让用户容易安装使用。
外观设计以模板形式发布出来,让程序人员可以在很大程度上节约外观设计的工作。
5.底层基于php
Joomla!采用PHP编写,由于PHP的易用性和开发者众多,并且PHP扩展接口灵活,有很多第三方产品。由于PHP系统的强大,反过来促进更多的开发人员投身其中,相互促进。
-----------摘自《joomla! 建站步步通》
综上所述,采用joomla!对于无论是初创团队还是大中型企业,都是一个不错的明智之选。当然,作为企业开发的架构和应用系统,我们还关心joomla!
是否适合团队开发,其中涉及,不同角色的团队人员如何在系统中协作?
协作开发的代码如何控制?
团队的开发和正式运营系统的环境如何部署才能满足不同阶段的需求?
不同开发任务如何在joomla!系统中进行分配?
joomla!对团队的代码资产的积累有何意义?
下文将对以上疑问进行解答,并在最后谈到了 joomla!对于团队开发的不足之处,以及应对之策。
1.joomla! mvc和独特的插件,模块,组件机制
joomla!系统设计纵向采用完善的mvc机制。有控制器,数据模型,表现层。
在团队开发中,大家可以各司其职,程序逻辑编写人员可以对控制器(controler)进行编程,
对象模型设计人员可以书写模型文件(model),美工可以通过修改表现层(view)文件实现美化。
当然,joomla! 本身的view机制虽然不错,但是在最后实现上,还是代码和html混合,让美工人员的工作
增加了难度,这点,在随后要讲到的优化的模板机制的机制里,会结合smarty对view进行完善。
joomla! 系统横向采用了独具特色的组件,模块,插件设计。
在团队开发中,一个具体的功能很可能就以开发一个组件或模块来体现。具体采用组件或模块
哪种方式来开发,就取决于具体任务。比如,在指定页面上显示一个信息,可能就采用模块方式来开发。
比如要开发涉及多个页面提交的功能,就会采用组件来做。至于插件,可能更适合于团队里水平比较
高水平的人士来开发一个功能短小精悍,但是对全局影响比较大的功能。比如,在实际项目里,要对
joomla!系统进行整体的加速,涉及到把编写规则将所有的cms内容按一定访问规则做个缓存,这就需要
编写一个插件,卡在joomla!的内容访问的时候被触发,将内容塞到memcache里。
2.svn版本控制
svn是php开发里最常用的版本控制方式。一般的,需要首先为每个项目建立一个svn库,随后在svn里为每个相关人员建立相应的帐号。
在joomla!开发中,由于每个任务的代码都会按模块或组件的方式来做,而且在后台部署前,不会对整体代码发生影响,
所以,一般情况下,每天由相关的开发人员或美工在开发完成后,本地测试审核完成后,进行提交即可。当然,
svn的机制还不是万能,仍然需要让团队人员培养在提交或开始修改文件前,需要先更新的好习惯。也仍然需要
让相关人员在提交版本的时候,在版本里加入对本次提交进行描述的说明。
3.优化的模板机制
joomla!的view机制让表现层的文件和逻辑控制相对独立,但是采用html和代码混编的形式却很是令美工MM头疼,当然,
美工MM的一个小错,也可以令整体系统core dump。所以,结合php里不错的smarty,对joomla!的view机制进行了改造。
如何改造,这里只写一个简单的例子。
在模块的tmpl(view的目录里)对default.php做个处理
然后模版sample.htm里
<%$list%>
4.开发环境和正式运营系统的部署步骤
首先,每个开发人员和测试人员必须在本机搭建一个joomla!运行 环境来进行代码提交前的开发和测试工作。
在这步工作里包括,给joomla!配置一个本地数据源,这步工作可以通过对joomla!的configration.php做改进实现。
具体原理是configration根据域名来连接本地配置的数据源。
随后在数据库里配置要运行的模块SQL,并将该SQL提交给数据库管理员,随后进行测试。
测试成功后提交到svn.
在正式运营系统里,首先由数据库管理员运行提交来的SQL完成模块配置。
随后由系统管理员或项目管理主管用以下的shell对svn提取最新版本的程序到一个临时目录,随后再由sync对目录里有更新的文件提交到正式环境。
这么做就实现了团队成员完成开发并测试后,直接将修改部分批量自动发布到生产系统里。
5.对团队的代码资产的积累意义
joomla!架构里已经对每部分的开发代码规范和实现做出了约定,所以,程序员开发出来的代码基本上都是一目了然,功能上
相对独立,确保了开发出来每个功能模不会重复开发。在我们团队的开发实践中,每阶段开发出来的模块组件插件基本上沿用下来。
可能几年前开发的功能块在现在的项目里仍然发挥着很大的作用,这样,保证了代码是“活的”。这样沿用下来,既减少了程序开发人员的开发工作量 ,
也确保了团队代码资产的"代代相传"。
当然万事万物都不是完美无缺。joomla!架构还是有一定的复杂性,在新人员加入时,还需要有一定的入门阶段。可能对希望人员立刻投入开发的团队而言,“远水不能
救近渴”,但是在如何提高入门速度上,和降低入门门栏上,作者倒有些行之有效的建议。首先可以让新人熟悉joomla!使用,先建立感性的认识,才能
在对joomla! 架构认识上更容易,这步推荐《joomla!建站步步通》,虽然该书主要面对初学者,建站人员,但不失为一本对joomla!操作了解
的捷径。其次,在 joomla!架构中,可以将某些部分分离出来为普通的php代码,比如逻辑部分封装为常规的php库,可以让对joomla!不太了解,但是php
很熟悉的人员编写这部分代码。
比如,封装一个交易库后,就可以直接在相应的joomla! 里进行使用:
并且在较难的组件编写中,可以对组件的进行重构,将其改写为切合自己开发流程的结构。