The point I'm trying to make is that there is no need for exposing so
much details to extension developers.
I'd prefer Rails 4 to only provide a single generator for an engine that
would fit all other cases covered by plugins and railties.
You don't have generators for Metal or other lightweight controller. Why
would you have for a lightweight Engine?
This will just confuse extension developers for no sensible benefit in
my opinion.
Em 05-06-2012 15:54, Luiz Felipe Garcia Pereira escreveu:
http://api.rubyonrails.org/classes/Rails/Railtie.html
"if you need to interact with the Rails framework during or after
boot, then Railtie is needed"
It shows examples of how to use a Railtie too.
There is no real difference between a non-rails gem and a basic
plugin. It's just pure ruby that gets loaded automatically for being
in the plugins directory.
Go to the code and you can always have the most updated documentation
explaining these things:
https://github.com/rails/rails/blob/master/railties/lib/rails/engine.rb
https://github.com/rails/rails/blob/master/railties/lib/rails/railtie.rb
But this is not a core issue.
On Tue, Jun 5, 2012 at 3:45 PM, Rodrigo Rosenfeld Rosas
<[email protected]> wrote:
Em 05-06-2012 15:40, Luiz Felipe Garcia Pereira escreveu:
The same rails guides like you pasted before shows a simple example of
"just a plugin" when it just extends the core class String.
I asked exactly what is the difference between this and a regular Ruby
non-Rails gem.
As for the differences between Railties and Engines, I'll quote the
docs (http://guides.rubyonrails.org/engines.html):
"A Rails::Engine is nothing more than a Railtie with some initializers
already set. And since Rails::Application and Rails::Plugin are
engines, the same configuration described here can be used in all
three."
And extracting from the Engine doc:
"it will automatically load models, controllers and helpers inside
app, load routes at config/routes.rb, load locales at
config/locales/*, and load tasks at lib/tasks/*."
I think it will also add lib/assets to the assets path nowadays, but
the doc might be outdated.
Assets are correctly processed by engines. But the explanation above didn't
talked about what a Railtie really is. What would it be useful for? They
only explain what an Engine does.
On Tue, Jun 5, 2012 at 3:21 PM, Rodrigo Rosenfeld Rosas
<[email protected]> wrote:
Em 05-06-2012 15:05, Luiz Felipe Garcia Pereira escreveu:
One word: Modularity
If it's a simple plugin, it doesn't need to be a Railtie and inserted in
rails
Could you please explain the differences about this and a regular Ruby
gem?
If it's something that extends rails/AR it can be a Railtie and take
advantage of that.
If it's an engine then it makes sense to add the Engine and have the
extra tools Rails::Engine provides.
What kind of improvements/benefits would you expect by using the former
instead of the latter?
If there is no real benefit, it would be better to always create an
engine and avoid user's confusion.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
