Am 28.11.2007 um 09:07 schrieb Space Ship Traveller: > 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?
Yes, I think it does. Engines only adds some crawling through additional directories looking for a certain file. > 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, at 8:59 PM, Nathaniel Brown wrote: > >> 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 11/27/07, Sven Fuchs <[EMAIL PROTECTED]> wrote: >> [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 >> >> >> >> -- >> Nathaniel Steven Henry Brown >> 604-724-6624 _______________________________________________ >> Engine-Developers mailing list >> [email protected] >> http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org > > _______________________________________________ > Engine-Developers mailing list > [email protected] > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org -- 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
