Resolving issue with custom content blocks and version listings

BrowserCms provides generators that can be used to create custom content blocks.  This means that you can create models that inherit all the other niceties that come packaged with BrowserCms, like version control, including in pages, etc.

One hiccup I discovered was that the wrong routes were being used for any custom content blocks, even those that come from the sanctioned bcms_blog plugin.

To duplicate the issue,

1. navigate to the cms content library: http://localhost/cms/content_library
2. select one of the custom content block category types (e.g., Blog, if you have the bcms_blog plugin installed)
3. create new content and edit and publish it several times
4. list the entries (e.g., Blog > Blog Post)
5. click on the entry that you edited
6. click on 'List Versions'
7. click on one of the versions
8. click on 'View Content'

You are rewarded with a HTTP 404 warning:

Why is the page not found?  Take a look at the route.  It suggests that the resource be found under the 'cms' namespace.  That seems to be the problem; the bcms_blog uses its own namespace (bcms_blog) to avoid route conflicts.  So what's responsible for putting 'cms' in the view links.  The correct namespaces are used up until 'List Versions' is clicked and the page is refreshed.

I tracked down the issue with the JavaScript to the app/views/cms/blocks/versions.html.erb view.  The existing code was assuming that all custom content blocks use the 'cms' namespace.  This may not be the case, as with the bcms_blog plugin that has it's own Rails::Engine and, consequently, it's own route namespace.

By introducing some logic in the view's JavaScript, we can dynamically determine what namespace should be applied:

And the code to determine 'cmd_namespace'...

There are certainly more elegant solutions, but here is my short term solution with an idea of how to solve it better.

Create a new content_block type

I have really enjoyed using BrowserCms for my content management Rails applications. Besides coming packaged with a lot of great features from the get-go, it is quite accommodating for personalizing the user's experience while still tapping into BrowserCms's great features. For example, content_block models have features such as security, version control, and WYSISYG form elements. When it is required to add models to your app, to gain access to those features, one easy method is to use the BrowserCms's content_block generator. Of course, BrowserCms does have documentation for this process, but I wanted to have greater control over the namespace for the generated elements. I had to make some changes to the BrowserCms generator, and was successful.

Create a new content_block type for a BrowserCms application in a specified namespace.

Note: the original browsercms generator for content_block was altered ever so slightly. This example depends on the changes made in my forked copy of browsercms.