Hello,
First off I hope this is the right place to ask this question. I am interested in the mountable apps feature of Rails 3. I read about them and that they are planned to be implemented.
I would like to know what’s the status on this? I want to upgrade an app that uses Pivotal Labs’ desert gem to Rails 3 and discard the gem.
Thank you,
I’ve been working on porting Desert apps to Rails 3 using engines, so I probably know as much about this stuff as anyone besides the rails-core folks. I expect Yehuda will have something to say though. In the mean time…
The basics of engines seem to be quite solid, though all the pieces aren’t yet complete. From the perspective of a Desert app, there are 4 pieces to support: model/controller classes, views, migrations and routes.
model/controller classes - Model and controller classes in an engine work, but they don’t combine with classes in your main application the way they do in Desert. If thing.rb is in both an engine and your main app, the main app’s version will be loaded and the engine’s won’t. There are ways to get effectively the same kind of composition Desert provides with minimal effort. I’ve been working on this front and it looks promising but this isn’t the right forum for that conversation. Feel free to email pivotallabsopensource@googlegroups.com for questions about Desert status.
views - Views in engines work great. As with classes, views in the main app win over ones in the engine.
migrations - No support for migrations in engines yet. I’m working on porting the Desert feature set to Rails 3 and it should be done soon, in time for making 3.0.
routes - We’re still talking about the best way to do routes and engines. I believe right now the routes in engines just get added at the end of the overall list of routes. Everyone involved wants to see something more flexible/granular, so I expect that will change.
By 3.0, Rails should support the same kind of composition you get with Desert, or close to it. I expect there might be some minimal library to make desert-like composition patterns easier - my proof of concept for that is two tiny methods and some boilerplate, so it’s not much work to maintain (or understand). If there were enough demand that might make it into Rails itself, but I don’t see the need for that yet.
This is great news that we might see some of this for Rails 3.0. For our project (BrowserCMS) the concept of mountable apps would make it much easier to support modular extensions as packagable gems. At current, we have our own code for loading Model/Controller/Views from gems in a way similar to engines, and something non-standard for dealing with routes. I would ideally like to be able to ditch all of that in favor of the 'correct' Rails solution if it meets our needs. If Engines will support all those isssues, that's great.
A couple of thoughts:
Ordering of Routes
A. Copy the static files from the gems into the public directory of the project, which can allow the web server to handle serving them. (BrowserCMS does this).
I dislike the copying files approach, it seems confusing and error-prone.
B. Have the plugin/gem serve the static assets from the gem through rails. (There are some plugins that do this whose names I can't remember).
This seems best, especially if this is "below" the rails caching layer, so that they can still be cached on filesystem/memcached/etc and served via webserver, even though they are being 'read' from in-place plugin/gem files via ruby code.
C. Do something fancy with symlinks (if the OS supports them).
Sounds like a bad idea too. We should try to be platform-agnostic if at all possible, which it is.
-- Chad