This project is archived and is in readonly mode.
Add way for plugins to map routes
-
Rich CavanaughGranted, 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.
-
DHHI actually have this almost ready. Should be done later today.
-
-
Rich Cavanaugh
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
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
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
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 endThen 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
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
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- 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. endSeems like it could work, no?
-
James Adam
Patch added to #329.
-
Caio Chassot
- 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
hum... cant reopen a ticket here?
-
Michael Koziarski- Milestone cleared.
- State changed from committed to open
You can't, but I can.
Reopening so david sees it.
-
Caio Chassot
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- State changed from open to resolved
Isn't this now fixed in 3.0 with the addition of engines?
-
