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, -- Andrei Erdoss -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mar 14, 2010, at 5:01 AM, Andrei Erdoss wrote:> 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.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. 1. 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. 2. views - Views in engines work great. As with classes, views in the main app win over ones in the engine. 3. 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. 4. 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. -- Josh Susser http://blog.hasmanythrough.com -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 =================The one issue I''m currently least clear on (and need to investigate more) is the ordering of routes from gems. Ideally, it would be nice if there were a way to allow gems to define when their routes are loaded relative to the project as well as other gems. For example, in BrowserCMS, the core gem needs to be absolutely last in order to serve as the ''catch all'' route. Other extension gems routes would ideally be loaded before the browsercms gem, but after the project specific routes. I.e. if my project is using three gems: gem ''browsercms'' gem ''bcms_module_a'' gem ''bcms_module_b'' It would great if the ''browsercms'' gem could specific it would be absolutely last, and the other two could specify ''before :browsercms'' in their configuration. That reduces the burden on developers who just want to use gems and not need to worry about route ordering. However, I can also think of situations where two gems might have ''conflicting'' routes that might require a project specific override to make sure that (for example) gem_a routes are loaded before gem_b''s routes. Static Assets ============Of the four items you mentioned, I would also add a fifth to consider: 5. Static Assets - These are files like javascript, stylesheets and even html files. Some extensions, specifically those that add a WYSIWYG editor like CKEditor (http://ckeditor.com/) to a project, require a lot of asset files which don''t necessarily conform to Rails conventions. There needs to be some way to make those files available as assets in the public directory. There are several possible solutions I can think of: 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). 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). C. Do something fancy with symlinks (if the OS supports them). -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Mar 15, 2010 at 8:41 AM, Patrick Peak <peakpg@gmail.com> wrote:> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.