Moving to Rails?

The following explanatory notes are meant to help you understand the differences between a classical CMS setup with CMS Fiona and one based on the Rails Connector. Read on if you wish to evaluate whether to move to Rails or not.

Editorial and Live System

CMS Fiona consists of an editorial and a live system. The editorial system serves to create the content. Furthermore, administrators can use it to define data structures such as fields, file formats, etc. and adapt them according to the requirements of the website.

The task of the live system is to generate web pages from the content. In a classical setup, the layouts (templates) stored in the CMS are used for this. In layouts, the structures of the web pages are defined, independently of the content. By means of a special query language for layouts, the content is inserted into the layout during the so-called export. The result of this is the final product, the web pages.

Editorial Content and Layout are Handled Equally

Technically speaking, layouts are a special kind of content, namely one that is used to display the editorial content. Layouts as well as the editorial content are maintained in the editorial system. There you can edit the layouts, move them to a different position in the file hierarchy, enter a title or any other field value, etc.

The unified handling of layout and editorial content is a central concept of CMS Fiona. Draft versions and released versions also exist for layouts, users can utilize the same tools for both content types. Layouts can be archived, are subject to the same workflow mechanisms as content, etc.

The Classical Live System is heterogeneous

The layout language of CMS Fiona makes it possible to use the functions of the live server in an easy and convenient way. Portlets, for example, can be included in web pages by means of a single layout instruction. The same applies if page access is to be restricted to particular user groups.

However, this approach requires several, partly disparate technologies on the live side. Updated content not only needs to be transferred to the live server for export. For implementing dynamic servers including personalization, access control, portlets, maybe also JSPs, the content needs to be delivered by the Portal Manager, processed by the Velocity Engine, the JSP Engine, and various filters. Using technologies as variable as these may quickly lead to unclear server setups on the live side.

Ruby on Rails is an Integrated Framework

In contrast to this, Ruby on Rails is an integrated framework. By means of the Rails Connector, content stored in the CMS database can be processed and displayed. On the live side, a setup that basically consists of Ruby, Rails, the Rails Connector, and the Search Engine, replaces the Template Engine, the Trifork application server, and the Portal Manager running in the latter.

The editorial system, on the other hand, remains unchanged. It is still required for comfortable content acquisition, for versioning, workflow control, etc.

Next to the database in which the editorial content is stored, Rails applications often utilize a live database for user-generated content such as comments, ratings, or personal preferences. For developers, access to the database content is transparent. The content display is elegantly encapsulated in views. This makes Ruby on Rails an ideal tool for efficiently developing modern Web 2.0 applications.

Moving to Ruby on Rails

Consider changing from a classical server setup with CMS Fiona alone to CMS Fiona plus Ruby on Rails if you plan to relaunch your website and make it more user-interactive. Ruby on Rails projects are handled just like software projects. JustRelate offers to completely manage and supervise such projects.