[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 svenfuchs@artweb-design.de 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)
on 28.11.2007 00:01
on 28.11.2007 09:00
My primary hope for 2.0 support is that we can get it to work without having to be so reliant on Engines to upgrade in order to get support in future versions of Rails. I've just realized how poor this dependency has become on the delay in ability to upgrade my projects as I rely on Engines to first upgrade. So with that said, I want to see what we can do to gear this upgrade to independence on the Rails tree. How can we make it so that Engines are drafted in such a way that they no longer "require" a specific Rails version, and if they are on some core mods such as Plugin loading, that it is done in a manner that doesn't rely, or relies on it as less as possible on Rails itself being compliant. Food for thought. I haven't considered this until now, so I'd like to discuss. Engines should be in Rails core, but if we simply can't get the Core team to agree to getting a sub-app (engine) as a default plugin's functionality, we need to be self sufficient in our own support for Rails. James, would be to chat about this on IM if you have a few min. Wouldn't mind hearing what your thoughts on this are in detail. Maybe we could setup a chat on campire and all discuss it?? If there's any support for this sort of approach, let's queue it up.
on 28.11.2007 09:09
I think this is a good idea. Whether it is possible or not, is another question... because I'll just go over to my crystal ball, and checkout what features will be in the next version.... ah!!... In reality, I think that Engines will always be playing catch-up. But, if interfaces can be designed to minimise the impact of changes within Rails, that is definitely a worthy goal. The problem is, to minimise the scope of the interfaces between Engines and Rails is to minimise the scope of Engines themselves. Engines replicates key functionality of Rails - its always going to be bound to the Rails way of doing things, and that will change from version to version... For example, the new naming scheme for views... does that work correctly with Engines? At the end of the day, if everyone can work on Engines and provide patches for the latest version of Rails, that is a pretty good solution. Deployment apps shouldn't be built on the latest and greatest technology without a good deal of caution, so this shouldn't really be a huge problem. Regards, Samuel
on 28.11.2007 10:59
Am 28.11.2007 um 09:07 schrieb Space Ship Traveller: > way of doing things, and that will change from version to version... > > For example, the new naming scheme for views... does that work > correctly with Engines? Yes, I think it does. Engines only adds some crawling through additional directories looking for a certain file. > >> mods such as Plugin loading, that it is done in a manner that >> Wouldn't mind hearing what your thoughts on this are in detail. >> Hi John, >> overall direction of possible refactorings. >> How do you think about specifying Engines' behaviour in RSpec? Having >> should >> That means that both of these could at least be deprectated: >> really lightweigt if both of the usages above would not be deprecated >> for >> # plugins are in Rails.plugins, so instead we need to use >> according >> >> artweb design http://www.artweb-design.de >> > Engine-Developers@lists.rails-engines.org > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org -- sven fuchs svenfuchs@artweb-design.de 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)
on 28.11.2007 11:03
Just to be sure to understand what you mean by "reliant on Engines to upgrade". Do you mean that a specific engine (like Macaque) that's written for "Rails Engines for Rails 1.2" should continue to work on "Rails Engines for Rails 2.0"? If that's the case this is what I meant by "backwards compatibility". I.e. not hard to do from what I've seen. But it's the usual tradeoff with backwards compatibility and supporting legacy stuff. The library is more heavyweight (which seems to be a "marketing issue" with Rails Engines) and users might get confused about all the options. Or do you mean that Rails Engines itself should be agnostic about the Rails version it is installed on at all? That might be a quite huge target to hunt for. Am 28.11.2007 um 08:59 schrieb Nathaniel Brown: > Plugin loading, that it is done in a manner that doesn't rely, or > Maybe we could setup a chat on campire and all discuss it?? > > > an executable spec story would probably make it easier for developers > > Engines.current.version = '1.0' > > > Just to be sure about this. Is this still the case? From what > > > > Nathaniel Steven Henry Brown > 604-724-6624 _______________________________________________ > Engine-Developers mailing list > Engine-Developers@lists.rails-engines.org > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org -- sven fuchs svenfuchs@artweb-design.de 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)
on 28.11.2007 11:07
As far as I am concerned it's the approach that ties us to Rails so dependantly. If we adjust the focus a bit, having a clear goal that is to be abstraction and a thin layer of dependence, I don't believe this shouldn't be a problem. Like I said, I'd like to chat it up and figure out how we should make it happen. If Engines depend solely on themselves for underlying functionality, then this would be an end of the line scenario. From what I have experience so far working with them, Engines provide a middle layer for Rails.
on 28.11.2007 21:12
On 11/28/07, Nathaniel Brown <nshb@inimit.com> wrote: > James, would be to chat about this on IM if you have a few min. Wouldn't > mind hearing what your thoughts on this are in detail. Maybe we could setup > a chat on campire and all discuss it?? I'll be in the #engines channel on freenode for the next couple of hours.
on 28.11.2007 21:14
On Nov 28, 2007 9:40 AM, Nathaniel Brown <nshb@inimit.com> wrote: > If Engines depend solely on themselves for underlying functionality, then > this would be an end of the line scenario. From what I have experience so > far working with them, Engines provide a middle layer for Rails. I'm also not clear what you're referring to here. Do you mean that plugins developed against the engines plugin are too tied to rails? Or that the engines plugin itself relies too much on the specifics of certain Rails' internals?