Comments on: Rails and Merb Merge: Rails Core (Part 4 of 6)

By: schof

schof — Wed, 10 Feb 2010 04:02:38 +0000

I wonder if we can't totally change how we approach things in Spree? Do you recall that we talked in person about apps such as Spree and Radiant and how they might work with "mountable apps?" Spree needs to fiddle with load paths and do a few non-standard things (at least not standard behavior for a plugin.)

Would you mind discussing this with us at some point? I'd love to get your insight into how we could pull this off. I think it would be a nice case study for the railtie/plugin functionality.

By: ruby on rails

ruby on rails — Wed, 03 Feb 2010 07:49:58 +0000

its really usefull info about Application, Object Improving ,Initialization Unifying Plugins and How Frameworks Became Plugins. i would lyk to use it .

By: Foy Savas

Foy Savas — Sat, 23 Jan 2010 05:12:05 +0000

Beautiful.

Earlier today I caught scent of the new direction Railties have taken (after opening up the code behind rails3_datamapper), and this post now perfectly complements my subsequent investigation into the Rails source.

Overall, I just have to say that the renewed direction of Rails is amazing. Even ActiveRecord is only a few fundamental features away from me being willing to use it over DataMapper. How did this ever happen!?

By: k776

k776 — Fri, 22 Jan 2010 23:40:26 +0000

I agree. When and how to load the railties file could use some explaination.

For gems, I'd assume you have lib/gem_name.rb load the railtie.rb file first off (e.g. http://github.com/dkubb/rails3_datamapper/blob/ma… This will go a fair way to making vendor/plugins redundent.

For plugins, would this be best in init.rb? From your post, is the :load_init_rb initializer example actually in Rails, or is this something the plugin itself specifies? And if that's the case, how does Rails load plugins now? Does it look for a vendor/plugin/your_plugin/railtie.rb ?

By: grimen

grimen — Fri, 22 Jan 2010 23:37:39 +0000

You guys really done a great job with Rails 3 for real! Everything just…makes so much sense for a guy like me that built LEGO all my childhood. =) Rails 3 makes Rails 2.3 feel annoying and rusty. ;D Can't wait until the day I Rails 3 and Ruby 1.9 runs stable and is compatible with "can't live without"-gems. I can't see any other web-framework on this level compete in the same start-field. (Which is truly sad too)

By: sam

sam — Fri, 22 Jan 2010 22:02:47 +0000

:before => still there

By: Sam

Sam — Fri, 22 Jan 2010 22:01:32 +0000

Something I found a bit confusing was where/when to require stuff during the init process. Do you require assisting gems in boot.rb or application.rb or deep inside your application.

boot.rb has changed from a "never touch this file" to a file that can/should be customized, what exactly should and should not be done there?

I have mixed feelings about the Application do; config.bla convention, it seems a bit magical how it introduces the config local in the block, in some way I would have preferred the more explicit approach at least that way you can do an arity check in the framework to ensure correct use.

On the performance side, that was vaguely mentioned, are performance regressions in AR and such considered ship stoppers for 3.0?

By: Matt Hooks

Matt Hooks — Fri, 22 Jan 2010 21:55:46 +0000

I'm assuming you're focusing more on cleanliness here than speed, but I was wondering how this would affect boot-up time?

By: wycats

wycats — Fri, 22 Jan 2010 21:06:13 +0000

Good catch. Both typos are fixed :)

By: Vladimir Andrijevik

Vladimir Andrijevik — Fri, 22 Jan 2010 20:52:11 +0000

I reckon I should finish reading the article before I write a comment about a typo. It seems that the explanation:

"Here, vendor/plugins defines an initializer called :load_init_rb, which runs after the application initializers."

doesn't quite agree with the code, since the call in initializer specifies ":before > :load_application_initializers", so :load_init_rb would run before the application initializers, no?