Chris Parrish wrote: > Nevermind. I wound up going the route of alias_method_chain-ing > SiteController's #show_page method. It makes things more tightly > coupled to Radiant but it's also closer to how it'd be if built-in. > > If anybody else out there is already using alias_method_chain on this > method in your extension, let me know. I'd sure love to avoid a 20 car > pileup there if a user has multiple extensions installed. > > -Chris
Could you simply add a before filter in that controller instead? before filters can stack up without overriding other filters in other extensions. And seems cleaner than an alias_method_chain before_filter :reload_routes, :only => :show private def reload_routes ActionController::Routing::Routes.reload! end And yes, since rake loads up its own rails process, it wont work for this. The only way I can see send a message like this into a rails form outside is via http. So your rake task would send a request to "http://mysite.com/reload_routes" which would do what you want. But that gets hairy too. Lets say you have multiple mongrels, 1 out of 4 got that request, and reloads its routes. All other mongrel don't have their routes reloaded. In general, I don't think you can use rake very well to modify the state of an already running rails process. You definitely want a hook in your extension to load the routes as needed. And remember that just because you updated the routes in the rails process that handled the admin requested route change doesn't mean its been updated in the other processes. This is a bug that would work fine in development mode with a single process, and suddenly cause weird issues in a more distrubed production deployment. -- Posted via http://www.ruby-forum.com/. _______________________________________________ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant