我只是一个Rails的使用者,很多的事情了解得并不深,视角和深度都有限,发这个帖子除了提出自己的疑问,更主要是希望听听大家意见,分享大家的心得。
engine被加入rails core曾经是一件很令我开心的事情,尤其是当我需要把一些固定的独立的MVC逻辑写成gem或者plugin的时候,原先大量的hack工作都消弭于无形。但是现在,我个人是觉得现在这个engine有点过了。
首先,作这个事情的目的有点过了,负责重构engine部分的Piotr Sarnacki坦言说作3.1里的这个重构的初始目标是mountable application,让一个process运行多个application, 比如说一个论坛,一个eshop可以打包作成一个gem或者类似的什么,需要的时候放进Gemfile就行。后来在同Carl和José讨论后决定作成mountable engine是一个近期更为可行的思路。实话实说,我很想知道为什么会想要让一个process运行多个application,分开运行有什么不好吗?包在一起不是把一大堆原本不需要rails实例关心的事情拉进rails了吗?
然后,手段也有点过了。举个例子,很多童鞋估计都看过这个[url=http://piotrsarnacki.com/2010/12/21/mountable-apps-tutorial/]Mountable apps tutorial[/url],为了能在plugin(or gem)下使用railtie里的generator,也为了测试需要,作者甚至直接加了一个假的rails project到生成的plugin里,而且把这个project放在生成的test/dummy文件夹(订证一点:也可以通过--dummy-path来制定位置)下。这本身就造成了很多混乱。首先这个rails实例并不只是test在用,rails这个命令也要用——生成的plugin里的script/rails直接就会去引用它,这是第一乱,test和development混成一团。然后,如果我不愿意用minitest测试,在创建plugin时加一个-T ,直接这个test文件夹就不会生成,这个dummy rails就不会存在,然后所有generator,所有作者引以为豪的类rails行为都无意义了。作者既然是参考enginex来作的这个plugin generator,为什么不看看enginex下大家为了测试engine plugin常用的diesel呢。
接着,在使用上也有点乱。举个例子,现在需要做一个投票功能的Gem,需要加一个migration。
好,现在有两种做法。
一个是把gem做成一个mountable engine,然后在gem下直接用rails g migration blabla生成migration ,然后在把这个Gem加入项目的Gemfile,再然后项目下就有一个rake命令(比如这个gem叫xyxy,命令就是rake xyxy:install:migrations),可以把这个migration拷到项目的db/migration文件夹内,并且自动解决掉migration序列号的问题。感觉还行,是吧?剔除这个功能本身的实现代码不看,是挺best practise的。
第二个是不把gem做成engine gem,就普通的一个lib文件夹,利用thor的一些方法做一个generator,给migration做一个template,用的时候把gem加入项目里的Gemfile,之后,直接在项目里rail g xyxy:migration,thor的方法也会自动解决序列号的问题。这个也挺干净利落,挺best practise的。
第一种做法用起来会很轻松,从头到尾就是几个现成的shortcut,两分钟完事了,而且几乎是个很坦然的无bug过程,但是生成的代码会有不少冗余,生成的mountable engine gem里有一堆你用不着但是不能删的文件夹;第二种做法要自己写一个generator,代码上很DRY,行行代码都是过脑子出来的,但也就意味着会有bug会花更多时间。
说这个例子与其说是提出问题,不如说是提出建议。engine除了mountable,是不是能做得更configurable,毕竟对绝大多数gem/plugin来说,只是需要对rails的一小部分进行扩展。写代码是很累的一个事情,我很喜欢shortcut,能不能只吃肉不挨打?
嗯...mountable engine里面的namespace和routes,建议有兴趣的朋友仔细实验过后再用,看起来不错,用起来也是pain in ass。
engine被加入rails core曾经是一件很令我开心的事情,尤其是当我需要把一些固定的独立的MVC逻辑写成gem或者plugin的时候,原先大量的hack工作都消弭于无形。但是现在,我个人是觉得现在这个engine有点过了。
首先,作这个事情的目的有点过了,负责重构engine部分的Piotr Sarnacki坦言说作3.1里的这个重构的初始目标是mountable application,让一个process运行多个application, 比如说一个论坛,一个eshop可以打包作成一个gem或者类似的什么,需要的时候放进Gemfile就行。后来在同Carl和José讨论后决定作成mountable engine是一个近期更为可行的思路。实话实说,我很想知道为什么会想要让一个process运行多个application,分开运行有什么不好吗?包在一起不是把一大堆原本不需要rails实例关心的事情拉进rails了吗?
然后,手段也有点过了。举个例子,很多童鞋估计都看过这个[url=http://piotrsarnacki.com/2010/12/21/mountable-apps-tutorial/]Mountable apps tutorial[/url],为了能在plugin(or gem)下使用railtie里的generator,也为了测试需要,作者甚至直接加了一个假的rails project到生成的plugin里,而且把这个project放在生成的test/dummy文件夹(订证一点:也可以通过--dummy-path来制定位置)下。这本身就造成了很多混乱。首先这个rails实例并不只是test在用,rails这个命令也要用——生成的plugin里的script/rails直接就会去引用它,这是第一乱,test和development混成一团。然后,如果我不愿意用minitest测试,在创建plugin时加一个-T ,直接这个test文件夹就不会生成,这个dummy rails就不会存在,然后所有generator,所有作者引以为豪的类rails行为都无意义了。作者既然是参考enginex来作的这个plugin generator,为什么不看看enginex下大家为了测试engine plugin常用的diesel呢。
接着,在使用上也有点乱。举个例子,现在需要做一个投票功能的Gem,需要加一个migration。
好,现在有两种做法。
一个是把gem做成一个mountable engine,然后在gem下直接用rails g migration blabla生成migration ,然后在把这个Gem加入项目的Gemfile,再然后项目下就有一个rake命令(比如这个gem叫xyxy,命令就是rake xyxy:install:migrations),可以把这个migration拷到项目的db/migration文件夹内,并且自动解决掉migration序列号的问题。感觉还行,是吧?剔除这个功能本身的实现代码不看,是挺best practise的。
第二个是不把gem做成engine gem,就普通的一个lib文件夹,利用thor的一些方法做一个generator,给migration做一个template,用的时候把gem加入项目里的Gemfile,之后,直接在项目里rail g xyxy:migration,thor的方法也会自动解决序列号的问题。这个也挺干净利落,挺best practise的。
第一种做法用起来会很轻松,从头到尾就是几个现成的shortcut,两分钟完事了,而且几乎是个很坦然的无bug过程,但是生成的代码会有不少冗余,生成的mountable engine gem里有一堆你用不着但是不能删的文件夹;第二种做法要自己写一个generator,代码上很DRY,行行代码都是过脑子出来的,但也就意味着会有bug会花更多时间。
说这个例子与其说是提出问题,不如说是提出建议。engine除了mountable,是不是能做得更configurable,毕竟对绝大多数gem/plugin来说,只是需要对rails的一小部分进行扩展。写代码是很累的一个事情,我很喜欢shortcut,能不能只吃肉不挨打?
嗯...mountable engine里面的namespace和routes,建议有兴趣的朋友仔细实验过后再用,看起来不错,用起来也是pain in ass。