Refinery::Blog routes

gistfile1.rb

Refinery::Core::Engine.routes.draw do
  # frontend
  namespace :blog do
    root :to => "posts#index"

    resources :posts
  end

  # backend
  namespace :blog, :path => "" do
    namespace :admin, :path => "refinery/blog" do
      root :to => "posts#index"

      resources :posts
    end
  end
end

# refinery.blog_posts_path - frontend
# refinery.blog_admin_posts_path - backend

Seems fairly clean!

with the engine now defined with "isolate_namespace Refinery::Blog" I don't think the route helpers will look like refinery.blog_posts_path. refinery_blog.posts_path maybe? Haven't seen the output when the module is nested.

Note that we're adding routes to Refinery::Core engine and that engine has name refinery. We will be adding all routes to Core engine so that user can simply do mount Refinery::Core::Engine => "/" in his route file and mount whole Refinery CMS app.

If we separate every engine routes and mount them at different locations then we can't have a backend. Example:

Refinery::Core::Engine.routes.draw do
  # some routes
end

Refinery::Blog::Engine.routes.draw do
  # some routes
end

mount Refinery::Core::Engine => "/"
mount Refinery::Blog::Engine => "/blog"

Because blog engine has its root as /blog in order to access backend from it we would have to use /blog/refinery/blog url.

My comment was based on the change made last week "isolate_namespace Refinery::Blog". If I understand this correctly it gives the blog engine its own namespace and a helper method for accessing application routes and creates a helper so the application can access its routes. It also makes it independent of the mount point.

My expectation was that since it is a constant the helper method that accesses the engines routes is either already available on the engine or could easily be added to the plugin. Something along the line of Refinery_blog.post_path which could pretty much be mounted anywhere. The backend would use the helper to get at the engine routes in a generic fashion.

If I'm following what you said above then the various engines should all be "isolate_namespace Refinery" which would make them all peers and the change checked in last week should be reverted.

Personally, I think putting them all in the same namespace is fine since it is very unlikely they will ever be mounted outside of a refinery app. With the full isolated namespace they could be mounted anywhere even without refinery present, but why would that ever happen.

isolate_namespace sets engine name (this can be overridden by using engine_name method), default scope for its routes, prefixes db tables and some other things so you're right about helper which allows main app or other engines to access blog routes but I'll emphasize once more the fact that we're adding blog routes to Refinery::Core and this way all those routes will be accesible using refinery helper (refinery is the name of Core engine).

Mount point of the engine becomes its root path so if we mount blog engine at /blog then we can't access its backend stuff from /refinery/blog - we would have to use /blog/refinery/blog so for example using refinery_blog.admin_posts_path would produce url /blog/refinery/blog.

isolate_namespace :refinery makes sense for one model engines like images, resources. Blog engine has multiple models and therefor db tables should be named like refinery_blog_posts, refinery_blog_categories - isolate_namespace sets those prefixes for us.

I know this is not a 1:1 explanation so please let me know if I left something out or was unclear.

Thank you for the explanation. I believe I understand the plan now. How long do you think it will take to get the new namespacing stable for core and the different engines like blog. I'm trying to deploy a reasonably current version of the code to a rails 3.1 site now, but have tripped over a few of the recent commits to core that have broken blog.

It all depends how much time we get to spend on it :-) it's not our day jobs so it's all spare time effort. We depend on contributors. Maybe a week of full time effort involved.

I am getting up to speed on the code, but I'm afraid this might be too comprehensive a change for me to be very helpful. I'm not pushing just asking, and I'm happy to help where I can.