Posted by & filed under Rails.

Building custom, simple, and user-friendly content management systems is perhaps the greatest challenge in developing web applications for clinical research. Standard, widely available platforms like WordPress are not designed out of the box to satisfy the specific needs of individual research projects that require robust data models and complex views controlled by a wide array of logical parameters. From a development standpoint, many of these features are not difficult to design so long as the custom content is completely administered by the developer. However, the requirements of many studies demand the creation of an application that can both balance the complex and specific logical functions of the application and the ability for a non-programmer researcher to administer custom content within the application.

With this dual demand in mind, I have been developing CommunicationBridge — an application that coaches people with aphasia — in a RoR framework and testing the limits of the popular Rails Admin gem as a CMS. My aim in this process is to determine if Rails Admin can meet three requirements:

  1. It can create individualized content for each user of the application and control the content that individual users will be shown and can interact with..
  2. It can be customized to mask or automate model associations in the creation process without compromising the data relationships
  3. It can be administered by a non-programmer researcher without excessive support

Rails Admin does an admirable job of understanding model relationships and translating them into a well-ordered and attractive CRUD interface. For object generation, Rails Admin is simple and effective. It also has built-in data exporting that makes it very easy for an administrator to extract data. However, it does require that the user have a relatively strong understanding of the data models that the interface is exposing. A CMS like WordPress has abstracted this model layer away so that the administrator can interact with the application in a more user-friendly way. My challenge has been to push Rails Admin to its limit to try to modify it to act more like a popular CMS without compromising the integrity of the application logic.

My open-ended verdict of Rails Admin as a CMS is that it can be used effectively for a variety of use cases. However, it has two notable weaknesses.

First, Rails Admin can quickly get overburdened with nested forms. If one wishes to restrict content generation within a single form, nesting will run as deep as the models are nested. To compensate for this, I have had to create some awkward model relationships or callbacks to mitigate this complexity.

Second, while Rails Admin form fields are customizable via partials and scoping, the DSL is awkward and the documentation is almost non-existent. For standard model relationships, achieving desired form modifications is easily attainable once the DSL is better understood, but I had great difficulty in trying to massage the interface to accommodate polymorphic relationships.

Overall, Rails Admin has been a useful tool for content generation and offers fine-grained control over complex UI logic. However, if the model relationships are not well-thought-out in advance, I can easily find myself jumping through hoops attempting to fit my application within the constraints of my CMS, rather than the opposite. This, however, is likely a problem for any application that demands a high degree of customization from an administrator.