On Sat, Apr 24, 2010 at 7:38 AM, Jeff Casimir <[email protected]> wrote: > Morning All, > > I've been thinking about extensions on and off for the past few > months. I really think installing extensions is too hard, here are > three ideas to ease the process. These assume that the work Jim has > done to gem-ify extensions is good and that all extensions should be > distributed as gems.
Josh French actually did the magic on this. There are still some things to be worked out with gems and UI regions but we have that wonderful problem to solve thanks to Josh's work. > > Sneaky Asset Management ===== > > I want to get rid of radiant:extensions:xyz:update and the Rails > router does most of the hard work. Let's establish that assets for > extensions are held in a place like "/public/extensions/xyz/assets/". > We'd need a route and controller that listened for that route, then > just pull the assets from within the gem (stored in some similarly > structured folder within the library). > > Of course a few users will want to customize the assets. So we need a > radiant:extensions:xyz:unpack_assets (basically the same as the old > "update") that copies the assets to the same place in > /public/extensions/xyz/assets. The Rails router will pickup these > static files with a higher precedence than the asset-finding-in-gems > route, so there is nothing complicated. > > Why do this? Reducing the steps and complexity for the installation. > Drop the gem in, require it, and you might be ready to go. It'd be > almost exactly like installing a normal gem for use in a Rails app. Look into http://github.com/fd/rack-gem-assets The problem with serving assets from the rails app is that it's not as well suited as apache, nginx or something like that for serving static assets. But correct me if I've missed some advancement in Ruby application servers. I wasn't involved in the original development of the extension system but an early question that came up was "why not just do a symlink instead of copying assets to public?". And the answer is that platforms differ in how that would be handled (windows). It's probably a solvable problem, but it was a "judo" decision to just go with an effective and easy solution to copy assets. Perhaps there's an argument for rack-gem-assets as a fallback to get going quickly and fair warnings that you should address the static assets outside the app. > > Explicit Migrations ====== > > Migrations, I think, need to go the other way. Rather than being > hidden away they should be in plain view. I think there should be a > generator that create the migration files and puts them in a normal > place, like /db/migrate/9318938_radiant_xyz_add_my_secret_table. > > Migrations, I find, are the area most in need of debugging when issues > arise with extensions. If we're moving towards the idea of Rails 3 > embeddable apps, I would want to have all my migrations in one place, > clearly organized, where I can understand what's going on. I think this is a little funny since you want static assets in an extension, but migrations in the main app. :-) I've been thinking about this problem a bit too. I like having the extension stuff in extensions (and don't really like the mess that can be made with public assets too), so initially I don't like this. But the problem with migrations in extensions and only in extensions is the uninstallation of extensions. You currently can't remove an extension from a repository, deploy and migrate your database down. You need to have the extension, migrate down, and then remove it. I've been thinking that a good strategy might be to copy all the migrations (as you suggest) but provide "uninstall" commands which will copy reversed extension migrations. So you could run "rake radiant:extensions:whatever:uninstall" which would create new migrations in your main project to remove any tables and columns. So you could then remove an extension from your repository and deploy without the need for the extension to continue to exist. > > Interactive Install Manager ===== > > Here's the install process I'd like to see: > >>> gem install radiant-xyz-extension >>> rake radiant:setup_extensions > > Welcome to the RadiantCMS Extension Management System. > The following extensions are available in the system: > > 1. XYZ [inactive] > 2. YAJ [inactive] > 3. LDU [inactive] > 4 OLD [active] > > Which extension would you like to activate / deactivate? (q to quit) > >>> 2 > > To activate extension YAJ I need to require the gem in your > /config/environment.rb, is that ok? (Y or N) > >>> Y > > Gem "YAJ" is now required. > > The extension also needs to make changes to your database with > migrations, would you like to generate those now? (Y or N) > >>> Y > > Generating migrations for extension "YAJ"... > /db/migrate/91830_radiant_yaj_create_table_for_yaj > /db/migrate/91830_radiant_yaj_modify_pages_for_yaj > > Migrations generated. Would you like to RUN the migrations now? (Y or N) > >>> Y > > (blah blah migration output) > > Extension YAJ has been setup. > > The following extensions are available in the system: > > 1. XYZ [inactive] > 2. YAJ [active] > 3. LDU [inactive] > 4 OLD [active] > > Which extension would you like to activate / deactivate? (q to quit) Awesome idea. > > > ============== > > That's my brainstorm for this morning. FYI, in my head I modeled this > install process after the EXCELLENT experience of installing Phusion > Passenger. > > - Jeff > > --- > Jeff Casimir > Jumpstart Lab by Casimir Creative, LLC > http://jumpstartlab.com > @jumpstartlab on twitter -- Jim Gay Saturn Flyer LLC [email protected] http://www.saturnflyer.com 571-403-0338 _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
