上海 RubyTuesday 活动召集!
主题:介绍 Rails Engine 报名:不需要 费用:咖啡店请自行点单 欢迎上海的 Rubyist 参加!
Rails::Engine allows you to wrap a specific Rails application or subset of functionality and share it with other applications. Since Rails 3.0, every Rails::Application is just an engine, which allows for simple feature and application sharing.
时间:2012 年 03 月 27 日(周二)晚上 6:30 至 9 点 地点:浦东新区世纪大道 8 号上海国金中心 D 座 B1 楼 LG1-37 室,COSTA COFFEE(国金中心店) 交通:位置在浦东陆家嘴的 Apple Store 旁边,提早到达的同学请负责占座 ^_^ 网址:http://www.dianping.com/shop/4600640
@lgn21st 非常实用的话题,一定参加。当你的应用功能越来越多,代码规模越来越庞大的时候,合适的方式组织应用会变得非常重要,Rails::Engine 是其中一种很棒的解决方案,期待 Ruby Tuesday!
#21 楼 @jhjguxin 自己组织呀,你就在市区中心,交通便利的地方比如新街口找个咖啡吧,然后发个帖子,AT 一下坛子里面各位南京的大大们就好了啊。 http://ruby-china.org/users/location/%E5%8D%97%E4%BA%AC
刚刚一个朋友跟我说,看到 Engine 就想到了 Engine Yard,我想想也是哦,在 Rails 3 以前,一看到 Engine,就想要一个词“丫的!”
A Rails Engine is a method for embedding one Rails applicaiton into another. Engines have been available as a plugin around for years, but it is now built in to Rails 2.3. RailsCasts: Rails Engine
All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality.
Engines fill a fairly specific need that we (my team) have, which is the development of multiple distinct Rails applications which share common components (authentication, reporting, importing data from hellish Excel), and ensuring that a means to apply patches & bug fixes across each of these applications, including models, controllers and views with the minimum of developer time spend on managing those updates. Need to roll-back to a previous version of the Reporting system? Just change the SVN external and everything within the Engine goes back to the way it was. With generators (less so with those that come with plugins, but this still holds true), the code would have to be regenerated back into the /app directory.
……
Engines have not recieved the blessing of the RoR core team, and I wouldn't expect any different, because it would be madness to include them in the core Rails. It's a mechanism far too easily [ab]used for things it's not actually suitable for. I did speak to Jamis (cc'd to DHH) about them quite some time ago, before plugins existed in a released form. Their advice was to reimplement our mechanism as a plugin, and if anything we were doing could not be achieved in this way, they would re-examine their plugin mechanism to see what could be adapted.
As it turns out, we can do everything we need within their plugins architecture, so we have a happy coexistance - Rails stays clean, but is flexibly enough to support our (hopefully not too outlandish) needs. It's not like we're forking the project or taking digging our heels in and taking a stand against anything.
So what am I saying? That engines should be stopped? Of course not. But I am saying that Rails will continue to send a signal with what’s included in the core that this is a sideshow project. It satisfies some needs for some people and that’s great. But the goal of Rails is to create a world where they are neither needed or strongly desired. Obviously, we are not quite there yet.
简单的说,如果不用 Subsctuct,节约出来的时间和精力足够我把 Substruct 作的事情推翻重做三遍以上了。
Rails engines allow our gem to have controllers, models, helpers, views, and routes…
For Rails 2.3, in order to make Engine work, Rails had to hook into Rubygems and check each gem that was loaded.
For Rails 3.x, we needed an explicit way to create engines, allowing it to work in any scenario, not only with Rubygems. Whit that in mind, Rails now ships with a new class Called Rails::Engine.
In Rails 3, a Rails::Engine does not have hard-coded paths. This means we are not required to place our models or controllers in app/
.
module MyEngine
class Engine < Rails::Engine
paths.app.controllers = "lib/controllers"
end
end
More info, please check out rails/railties/lib/rails/engine/configuration.rb
An engine has several initializers that are responsible for making the engine work.
>> Rails::Engine.initializers.map(&:name)
=> [:set_load_path, :set_autoload_paths, :add_routing_paths, :add_locales, :add_view_paths, :load_environment_config, :append_assets_path, :prepend_helpers_path, :load_config_initializers, :engines_blank_point]
initializer :add_routing_paths do |app|
paths.config.routes.to_a.each do |route|
app.routes_reloader.paths.unshift(route) if File.exists?(route)
end
end
The Rack specification clearly outlines the API used by Rack applica- tions to communicate with a web server and between themselves: A Rack application is a Ruby object (not necessarily a class) that responds to call. It takes exactly one argument, the environment, and returns an array of exactly three values: the status, the headers, and the body.
By following the Rack API, a web framework could use Rack web servers adapters instead of providing its own, removing the duplication of effort existing in the Ruby community.
While Rails 2.2 already provided a simple Rack interface, Rails more closely embraced Rack and its API in version 2.3. However, the Rack revolution really happened in Rails 3.
New mountable engines come with fully isolated namespace. which let an e-commerce soltuion like Spree, a Forum like Forem or a CMS like Refinery or Locomotive in you own Rails application.
rails plugin new
for Rails 3.1ignore...
再送上一些学习资料
http://www.astjohn.ca/2011/08/06/rails-31-engines-mountable-or-full-part-1/ http://www.astjohn.ca/2011/08/07/rails-31-engines-mountable-or-full-part-2/ http://piotrsarnacki.com/2010/09/14/mountable-engines/ http://piotrsarnacki.com/2010/12/21/mountable-apps-tutorial/ http://stackoverflow.com/questions/6118905/rails-3-1-engine-vs-mountable-app