Yeah, that's why I was saying perhaps a parse-and-eval method might work:
1) Load the "#{RAILS_ROOT}/config/routes.rb" file as text.
2) Find and strip out the lines that contain the beginning and end of
the block.
3) eval the file in the local context of the define_routes block.
Not elegant, I know, but effective.
Sean
Matt Parrish wrote:
> Yes, that's basically what my extension is doing. But it does
> require a slight change to config/routes.rb, because vendor/radiant/
> config/routes.rb is where the ActionController::Routing::Routes.draw
> { |map| } block is. And I don't think we can have that there and in
> config/routes.rb
>
> Matt Parrish
> http://www.pearware.org
>
>
> On Jun 2, 2007, at 11:00 AM, Sean Cribbs wrote:
>
>
>> Here's another option, one you may have considered already.
>>
>> Extension routes are loaded before the Radiant routes and all of
>> this is
>> taken care of by Radiant::Initializer. You could either extend
>> Radiant::Initializer or use the define_routes block in the
>> extension to
>> load the primary routes.rb. I'm not sure whether you should parse,
>> process, and eval it or some other method, but it is conceivably
>> possible. I think it has to do with generators or rake tasks, but
>> Radiant does something similar to redefine some stock Rails stuff.
>>
>> Sean
>>
>> Matt Parrish wrote:
>>
>>> Okay, cool. As for the routes, my extension currently has the user
>>> modify config/routes.rb a bit since /vendor/radiant/config/routes.rb
>>> calls the Rails route initialization. If we could change it so that
>>> Radiant hooks into that process differently, then the developer can
>>> write config/routes.rb as is done traditionally. It doesn't look
>>> like the Rails guys have given an easy way to hook into that process,
>>> although it could easily be a one line call to Radiant to load its
>>> routes at the end of the ActionController::Routing::Routes.draw { |
>>> map| } block. However Radiant's /vendor/radiant/config/routes.rb
>>> would need to change slightly to be like how extensions define
>>> routes.
>>>
>>> Here's the change I see. Instead of how Radiant currently does
>>> config/routes.rb and vendor/radiant/config/routes.rb as
>>>
>>> load File.join(RADIANT_ROOT, "config", "routes.rb")
>>>
>>> and
>>>
>>> ActionController::Routing::Routes.draw do |map|
>>>
>>> # Admin Routes
>>> map.with_options(:controller => 'admin/welcome') do |welcome|
>>>
>>> ...
>>>
>>> end
>>>
>>>
>>> respectively. It could look like this:
>>>
>>> ActionController::Routing::Routes.draw do |map|
>>>
>>> # Place for Rails Routes
>>> map.with_options(:controller => 'admin/welcome') do |welcome|
>>> ...
>>>
>>> RadiantRoutes.define_routes(map)
>>> end
>>>
>>> and
>>>
>>> class RadiantRoutes
>>> def self.define_routes(map)
>>>
>>> # Admin Routes
>>> map.with_options(:controller => 'admin/welcome') do |welcome|
>>>
>>> ...
>>>
>>> end
>>> end
>>>
>>> What do you think about making a change like that? We would just
>>> need to make sure that config/routes.rb can see the RadiantRoutes
>>> class. It wouldn't affect the current Radiant usage, but would allow
>>> for developers to work with config/routes.rb like normal. The
>>> RadiantOnRails extension is like the first solution, except that I
>>> have the user create a class RailsRoutes with a define_routes method
>>> that my extension calls. I think the second solution here would be
>>> preferred.
>>>
>>> Matt Parrish
>>> http://www.pearware.org
>>>
>
> _______________________________________________
> Radiant mailing list
> Post: [email protected]
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
>
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
