Rails 3.1:引擎与可安装应用程序
有人可以帮助我理解 Rails 引擎和可安装应用程序之间的区别吗?在 Rails 3.1 中,您可以使用“rails new plugin ___”命令创建任一插件。
rails plugin new forum --full # Engine
rails plugin new forum --mountable # Mountable App
您什么时候想使用其中一种而不是另一种?我知道您可以将引擎打包为宝石。可安装应用程序不就是这样吗?还有哪些其他区别?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我注意到以下内容:
完整引擎
使用完整引擎,父应用程序会继承引擎的路由。无需在
parent_app/config/routes.rb
中指定任何内容。在 Gemfile 中指定 gem 足以让父应用程序继承模型、路由等。引擎路由被指定为:没有模型、控制器等的命名空间。这些是立即的
可由父应用程序访问。
可安装引擎
默认情况下,引擎的命名空间是隔离的:
使用可安装引擎,路由是命名空间的,父应用程序可以将此功能捆绑在单个路由下:
模型、控制器等与父应用程序隔离- 虽然助手可以轻松共享。
这些是我发现的主要差异。也许还有其他人?我已在此处询问,但尚未收到回复回复。
我的印象是,由于完整的引擎不会将自身与父应用程序隔离,因此最好将其用作与父应用程序相邻的独立应用程序。我相信可能会发生名称冲突。
当您想要避免名称冲突并将引擎捆绑在父应用程序中的一个特定路由下时,可以使用可安装引擎。例如,我正在致力于构建我的第一个专为客户服务而设计的引擎。父应用程序可以将其功能捆绑在一个路径下,例如:
如果我的假设偏离了我的假设,请有人告诉我,我将修复此响应。我写了一篇关于该主题的小文章 这里。
I have noticed the following:
Full Engine
With a full engine, the parent application inherits the routes from the engine. It is not necessary to specify anything in
parent_app/config/routes.rb
. Specifying the gem in Gemfile is enough for the parent app to inherit the models, routes etc. The engine routes are specified as:No namespacing of models, controllers, etc. These are immediately
accessible to the parent application.
Mountable Engine
The engine's namespace is isolated by default:
With a mountable engine, the routes are namespaced and the parent app can bundle this functionality under a single route:
Models, controllers, etc are isolated from the parent application - although helpers can be shared easily.
These are the main differences I have spotted. Perhaps there are others? I have asked over here, but have yet to receive a response.
My impression is that since a full engine does not isolate itself from the parent application, it is best used as a standalone application adjacent to the parent app. I believe name clashes could occur.
A mountable engine could be used in situations where you want to avoid name conflicts and bundle the engine under one specific route in the parent application. For example, I am working on building my first engine designed for customer service. The parent application could bundle it's functionality under a single route such as:
If I'm way off in my assumptions, someone please let me know and I'll fix this response. I have made a small article about the subject here.
这两个选项都会生成一个引擎。不同之处在于
--mountable
将在独立的命名空间中创建引擎,而--full
将创建一个共享主应用程序命名空间的引擎。差异将通过 3 种方式体现出来:
1) 引擎类文件将调用
isolate_namespace
:lib/my_full_engine/engine.rb:
lib/my_mountable_engine/engine.rb:
2) 引擎的
config/routes.rb
文件将被命名为:完整引擎:
安装的引擎:
3) 控制器、助手、视图和资产的文件结构将被命名为:
说明
--full
选项的用例似乎非常有限。就我个人而言,我想不出任何好的理由为什么您希望将代码分离到引擎中而不隔离名称空间 - 它本质上只会为您提供两个紧密耦合的应用程序,共享相同的文件结构以及所有冲突和代码泄漏这需要。我见过的每一篇文档都演示了
--mountable
选项,实际上是当前的 边缘指南 强烈鼓励您包含隔离命名空间
- 这与使用--mountable
而不是相同 - -完整
。最后还有术语混乱:不幸的是,rails plugin -h 显示了以下描述:
这给人的印象是您使用
--full
创建一个“引擎”,并使用--mountable
创建其他称为“可安装的应用程序”,而实际上它们都是引擎 - 一个具有命名空间,一个没有。这必然会导致混乱,因为希望创建引擎的用户可能会认为--full
是更相关的选项。结论
rails 插件新东西 --full
= 应用程序命名空间中的引擎。 (为什么要这样做?)rails 插件新东西 --mountable
= 具有自己的命名空间的引擎。 (太棒了)参考文献
Both options will generate an engine. The difference is that
--mountable
will create the engine in an isolated namespace, whereas--full
will create an engine that shares the namespace of the main app.The differences will be manifested in 3 ways:
1) The engine class file will call
isolate_namespace
:lib/my_full_engine/engine.rb:
lib/my_mountable_engine/engine.rb:
2) The engine's
config/routes.rb
file will be namespaced:Full engine:
Mounted engine:
3) The file structure for controllers, helpers, views, and assets will be namespaced:
Explanation
The use case for the
--full
option seems to be very limited. Personally I can't think of any good reason why you'd want to separate your code into an engine without isolating the namespace as well- It would essentially just give you two tightly coupled applications sharing identical file structures and all the conflicts and code leakage that entails.Every piece of documentation I've seen demonstrates the
--mountable
option, and indeed the current edge guide strongly encourages you to includeisolate namespace
- which is the same as saying use--mountable
over--full
.Finally there's terminology confusion: Unfortunately
rails plugin -h
shows the following descriptions:This gives the impression that you use
--full
to create an "engine" and--mountable
to create something else called a "mountable application", when in fact they're both engines - one namespaced and one not. That's bound to lead to confusion as users looking to create an engine will likely assume that--full
is the more relevant option.Conclusion
rails plugin new something --full
= Engine in your app's namespace. (Why would you?)rails plugin new something --mountable
= Engine with it's own namespace. (Awesome)References
我也想知道,因此,最终来到了这里。在我看来,早期的答案基本上涵盖了这个问题,但我认为以下内容也可能有所帮助:(
之间没有区别
对我而言)特别感兴趣的是以下事实:和
i was wondering the same and, hence, ended up here. it seems to me that the earlier answers basically cover the question, but i thought the following might help as well:
of particular interest (to me) is the fact that there is no difference between
and
我对差异的理解是引擎就像插件一样,可以为现有应用程序添加功能。虽然可安装应用程序本质上是一个应用程序,并且可以独立存在。
因此,如果您希望能够单独运行它或在另一个应用程序中运行它,您将创建一个可安装的应用程序。如果您打算将其添加到现有应用程序中,但不单独运行,则可以将其设为引擎。
My understanding of the difference is that engines are like plugins, and add functionality to existing applications. While mountable apps are essentially an application, and can stand alone.
So if you want to be able to run it by itself or within another application you would make a mountable app. If you intend for it to be an addition to existing applications, but not run by itself you would make it an engine.
我认为,区别在于可安装应用程序与主机应用程序是隔离的,因此它们不能共享类 - 模型、帮助程序等。这是因为可安装应用程序是一个机架端点(即本身就是一个机架应用程序) )。
免责声明:像大多数人一样,我才刚刚开始使用 Rails 3.1。
The difference, I believe, is that a mountable app's are isolated from the host app, so they can't share classes - models, helper etc. This is because a Mountable app is a Rack endpoint (i.e a Rack app in its own right).
Disclaimer: I have, like most, only just started toying with Rails 3.1.