Hi James, I've commited everything to the Engines repo now: http://svn.rails-engines.org/test/engines/rails_2.0/
Thanks for granting me commit access! Am 02.12.2007 um 23:16 schrieb James Adam: > I believe the rendering mechanism for ActionMailer has changed, I'll > investigate this. Great. > See Pascal's comments about the $LOAD_PATH - I > believe it is in the correct order. I'm not sure that your test for > this makes sense, but I'll double check this. Yes, I'm pretty sure my test is just plain crap. I'll change that. > While code mixing might be deprecated, it could be worth keeping parts > of it around - for instance, I'm quite keen on moving the explicit > declaration of "controllers and helpers" out of the depths of the > Dependencies extensions to somewhere more visible. Aha, ok. Well, I've put porting the tests for that on my todo list. >> * moved Rails.plugins to Engines.plugins > This could be problematic, as existing migrations will refer to > Rails.plugins. I suggest that we add a method to the Rails module > which returns the result of a call to Engines.plugins. Ok. >> * moved extensions to an accessible attribute on Engines and >> extensions loding from init.rb to Engines.init to declutter the >> init.rb file. >> Engines and Engines::Plugin are pretty lean now. I moved stuff out of >> init.rb because I thought it would be a nice idea to have the >> Engines plugin >> behave just like a normal Rails plugin if it hasn't been "booted". >> I think this >> also responds to your consideration to mess as little with Rails >> core code as >> possible. > I'm not sure if I follow you here - by 'not booted', presumably you > mean that the line hasn't been added to the top of environment.rb? Yes. "booted" because it happens right after Rails' own boot.rb has finished ... i.e. just "present" or "included". I might be wrong but I think previously you'd had to remove the entire Engines plugin from the plugins directory to deactivate it. Or comment out everything in the init.rb file? I'm not sure if it's actually a big win to be able to deactivate it by commenting out the line in environment but it feels a little cleaner (ignoring the fact that it doesn't really work that way when there are map.from_route mappings in routes.rb). > I sympathise, but I think it's possibly wise to avoid messing around > with Ruby core classes unless it's unavoidable. I'd be more > comfortable setting the defaults in a more explicit way. Ok, I'll revert that. > The distinction here is that the only file in our "config" directory > would be the routes.rb file. Is it really worth creating a directory > to hold that single file? Personally, I don't think so. I also feel > that it's worth breaking away from the "your plugin is a mini > application" mindset that mirroring the default app layout so > completely would promote. Hmm, I guess that's a matter of taste probably. Ok, strike that. > Anyway - I need to spend some time merging what you've done into my > own refactorings, and then I'm sure I'll have more to add. Thanks for > your work so far Sven! It's a lot of fun, actually. And I'm happy to be able to contribute to such a great project. :) -- 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
