A developer's journey through BrowserCms.

Friday, April 5, 2013

CKEditor instances and Ajax

I spent a little time trying to figure out how to manage the CKEditors on an authoring page. For the bulk of my solution, I give credit to StackOverflow. As noted in the example below, I did need to comment out the line with CKEDITOR.replace(instance); to get things working on my end.

If I understand this issue correctly, because I am using Ajax, the instances remain in memory. As I navigate to each page in my wizard, Ajax is used to get a fresh copy of the page partial. Each time the editor page is requested, the id values for the CKEditor instances is slightly different. CKEDITOR.instances lists registered editors that have been loaded. Those instances need to be cleared out in order to successfully load the new CKEditor instances.

I created a new helper method to generate CKEditor without the option to switch to plain text. Here is the template:

Here is the form helper:

Thursday, April 4, 2013

It would help to check Capybara output!

I was battling with my cucumber tests recently. The problem was that the wrong user was being setup for the tests. I was seeing 'unauthorized access' in Firefox (WebDriver). Also, WebDriver's activity is logged in 'logs/test' and that was reporting unauthorized access as well.

Sure enough, I was mistaking 'registered user' for an authorized user. A registered user does not have special editing and publishing permissions (at least for vanilla BrowserCms).

When I correctly assigned the user login, I got a little further.

Ok; almost there. The remaining issue was that my cmsuser account is getting truncated after the first test. That explains why the first scenario works and the others don't.

Finally, tests are passing again.

./bin/cucumber -r features --drb features/pages.feature

Project cucumber features

Wednesday, April 3, 2013

testing's delicate balance

When adding scenarios, especially those with the @javascript tag, you may need to be aware of tables that should not be truncated, unless after truncating the tables they are seeded for the next run. This latter solution is not one we are currently using. Instead, we include the tables that are not changing, that are being used in multiple tests, in the list of exception tables that will not be truncated at the end of each scenario.

In addition to adding exception tables, you will need to include more seed data for the tables that are not being changed and are used across several scenarios.

I created some custom content blocks for article and layout records. Unless a separate Rails::Engine is used to generate routes, it appears that content blocks must reside under the Cms:: namespace. By creating BcmsMy401k::Engine, I was able to establish the BcmsMy401k:: namespace. This also meant that I needed to add routes via BcmsMy401k::Engine instead of Rails::Application.

For some reason, however, the routes are being loaded twice. I will need to figure out why, but for now, I check to see if the routes were loaded already for the BcmsMy401k::Engine. I do this by analyzing the routes already drawn. I chose to check by using the ActionDispatch::Routing::RouteSet::NamedRouteCollection#names method. If the count is greater than 0, then they've already been loaded. The routes should only be loaded one time. This solution will allow me to move forward; I'll have to investigate a better solution later.

Related resources:

Monday, April 1, 2013

app/models/cms.rb
This little file is responsible for appending "cms_" to all the table names for Cms models so that the actual table names in the database are not actually prefixed.  The only exception seems to be Cms::Attachment.
module Cms
  def self.table_name_prefix
    #'cms_'
    ''
  end
end
In order for my tests to run in my application that uses browsercms, I needed to configure an empty string to be returned.  The development environment had already weeded out 'cms_' somewhere else in the code.  The test environment needs to have this value set to empty string.