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
