This project is archived and is in readonly mode.

#1450 ✓resolved
DHH

Add way for plugins to map routes

Reported by DHH | November 23rd, 2008 @ 05:31 PM | in 3.0.2

Two ideas: Either have something like a routes.rb type convetion ala init.rb or add ActionController::Routing::Routes.chisel that would engrave routes into the map that wouldn't go away when the map is reloaded. I'm partial to the later.

Comments and changes to this ticket

  • Rich Cavanaugh

    Rich Cavanaugh November 26th, 2008 @ 04:29 PM

    Granted, it would need some updating for HEAD but, what about the ideas implemented in #329? This sounds a fair bit like providing an API such as chisel. I'm happy to update the patch with any new ideas.

  • DHH

    DHH November 26th, 2008 @ 04:39 PM

    I actually have this almost ready. Should be done later today.

  • DHH

    DHH November 26th, 2008 @ 07:28 PM

    • State changed from “new” to “committed”

    config/routes.rb will now be eval'ed when in a plugin.

  • Rich Cavanaugh

    Rich Cavanaugh November 30th, 2008 @ 10:13 PM

    This approach is certainly far simpler and cleaner to implement but it basically takes all control out of the app developer's hands. For example, what happens if a plugin provides routes you don't want?

  • DHH

    DHH December 1st, 2008 @ 12:43 AM

    If it's reasonable for them to be optional, the plugin just shouldn't auto add but give a method where you can add them by hand.

    Do you have any real cases of this though? Sounds pretty unlikely. Presumably the plugin would only add routes needed for its operation.

  • Josh Susser

    Josh Susser December 1st, 2008 @ 02:16 AM

    I think it's not a big issue whether they can be optional. But it's good to give the app developer control about where in the route precedence a plugin's routes go. Desert does this with a way to embed plugin routes within the main routes file. e.g.:

    
    map.resources :posts
    map.routes_from_plugin(:user)
    map.namespace :admin do # ...
    

    Controlling order can be important when you've got wildcards to worry about. Of course there's a tradeoff between the convenience of a plugin being able to add its own routes and the ability to control precedence. We've built a lot of apps using Desert and we find the control preferable to convenience.

  • DHH

    DHH December 1st, 2008 @ 02:42 AM

    When you need that level of control, I think it's better to let the plugin expose its routes via a method. Like

    
      def MyPluginRoutes.draw(map)
        map.resources :posts
      end
    

    Then in your routes.rb, you just

    
      map.resources :my_posts
      MyPluginRoutes.draw(map)
    

    That's how we added routes before this automation at 37s anyways.

  • Josh Susser

    Josh Susser December 1st, 2008 @ 01:34 PM

    DHH: that's just what I was saying, but with less supporting syntax. I guess the question is can you have it be automatic when you don't care about precedence but manual when you do?

  • DHH

    DHH December 1st, 2008 @ 01:53 PM

    Do explore an API for that. I kinda doubt it. The loading order would have to be vastly different. But do look into it.

  • James Adam

    James Adam May 1st, 2009 @ 06:28 PM

    • Tag set to 2.3.2, engines, plugin, routing

    I've added some thoughts to #329, and I believe that we might be able to cover the "manual when I want it, automatic when I don't care" with my approach.

    Without repeating what I've written there, it should be possible to detect if a bundle of routes has been applied or not, and then apply any unbundled routes after all of the application ones. In essence:

    
    ActionController::Routing::Routes.draw do |map|
      map.connect "/app-specific" # ...
    
      map.bundle :plugin_one
    
      map.connect "/another-app-override"
    
      map.bundle :plugin_two
    
      # at this point, any loaded bundles that have not been explicitly referenced are applied, in plugin load order.
    end
    

    Seems like it could work, no?

  • James Adam
  • Caio Chassot

    Caio Chassot July 10th, 2009 @ 04:59 AM

    • Assigned user set to “DHH”

    Looks like f2ee056 regressed 3cc9d1c. That is, plugins can't have routes anymore, but engines do.

    f2ee056 Added view path support for engines [DHH] 3cc9d1c Let all plugins not just engines have a config/routes.rb file

    routing_files was replaced by add_engine_routing_configurations, which again uses #engines instead of #plugins.

  • Caio Chassot

    Caio Chassot July 10th, 2009 @ 05:05 AM

    hum... cant reopen a ticket here?

  • Michael Koziarski

    Michael Koziarski August 23rd, 2009 @ 11:32 PM

    • Milestone cleared.
    • State changed from “committed” to “open”

    You can't, but I can.

    Reopening so david sees it.

  • Caio Chassot

    Caio Chassot August 24th, 2009 @ 12:11 AM

    Urls to referenced commits:

    Let all plugins not just engines have a config/routes.rb file http://github.com/rails/rails/commit/3cc9d1c5ad1639283b43ee2b6099cb...

    Added view path support for engines [DHH] http://github.com/rails/rails/commit/f2ee056873b84f8917e72d87181e1a...

  • Ryan Bigg

    Ryan Bigg June 16th, 2010 @ 11:37 PM

    • State changed from “open” to “resolved”

    Isn't this now fixed in 3.0 with the addition of engines?

  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to 3.0.2
    • Importance changed from “” to “Medium”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Referenced by

Pages