[sending this to engine-developers, please advise me if this is for some reason not correct]
Hi John, to get a better overview how things are interrelated in the current implementation I've gone through a first coarse refactoring towards the Rails 2.0 plugin architecture. I've checked my results in here so everybody can have a look at it: http://svn.artweb-design.de/engines/dev/vendor/plugins/engines Of course that's not meant as a serious proposal (there are not even any working tests) but as an exploration of the existing code and the overall direction of possible refactorings. Like you said the Engines implementation can be slimmed down greatly because Rails now ships with some important features itself. Please criticise any changes I've made to overall structure. Also, some questions arose: 1. Tests How do you think about specifying Engines' behaviour in RSpec? Having an executable spec story would probably make it easier for developers to figure out what Engines actually does. As I have to go through all the tests next, I could easily take notes accordingly and transform them to an RSpec story. 2. Backwards compatibility There are some notes/flags about legacy support and deprecated config support. Do you feel these should be continued to supported? Or should Engines for Rails 2.0 remove the previously deprecated features? Also there's at least one feature that could be implemented more cleanly by changing the api: Previously the plugin's init.rb was evaluated in the scope of the initializer (I guess) while it is now evaluated in the scope of the plugin instance itself. This allows to directly access the plugin attributes from within the init.rb file. That means that both of these could at least be deprectated: Engines.current.version = '1.0' Rails.plugins[:name] = '1.0' ... in favor of just: version = '1.0' When you look at http://svn.artweb-design.de/engines/dev/vendor/plugins/engines/lib/engines/plugin/loader.rb I've added some notes about how the loader could be implemented really lightweigt if both of the usages above would not be deprecated but entirely removed from Engines. How do you think about that? To help users with the migration there could be a simple generator script that just replaces these occurences in the plugins init.rb files if there are any at all. This would allow to have an even lighter Engines implementation. That said, this of course could also just be deprecated in Engines for Rails 2.0 and removed in the next following release quite quickly. 3. Question about routing / plugins In the routing extensions there's this comment: Engines::RailsExtensions::Routing#from_plugin # At the point in which routing is loaded, we cannot guarantee that all # plugins are in Rails.plugins, so instead we need to use find_plugin_path Just to be sure about this. Is this still the case? From what Rails::Initializer#process says, at this point (when routing is loaded), all the plugins should be loaded. 4. Question about an engine's views behaviour Is my understanding correct that Engines views do not overwrite according views in the application? -- sven fuchs [EMAIL PROTECTED] artweb design http://www.artweb-design.de grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone) d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile) _______________________________________________ Engine-Developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
