Table of Contents
Content Management
Requirement
- Content is a document that may contain text, images, videos and files.
- Currently the document can be a single page document where in all the content will be shown at one go.
- An editor should be available that allows to create/edit the document and allowing basic formatting.
- There should be an ability embed files, videos, images in the document along with the text contents.
- The assets like images, files, videos can be optionally be stored over the cloud e.g Amazon S3
- Provide access control for the document, so that it can be viewed only by selected set of users (the roles and rules for access control are yet to be defined)
- Changes/edits made to a document should be versioned i.e. the application should be able to identify all the changes made to a document and should switch back to previous revisions. (take an example of how doku wiki is implemented. Each page has different versions as and when it gets updated and there is a UI where all the versions are listed and user can view each revision and also make it as current)
- The document can have states like “draft”, “live”, “expired”. “live” indicates that the document is available for other users.
- There should be an ability to publish/republish a specific version of the document.
- There should be an ability to publish and expire a document based on date range.
What is currently available with community engine
- Editor that allows formatting of text (tinymce).
- Upload and management of images and embedding it inside the document.
- Linking to external media files (flash, quicktime, wmv) and embedding it inside the document.
- Storing of the assets/images to Amazon cloud.
What is not available and needs to be built
- Maintaining versions of the document.
- Publish/republish a version of the document.
- Publish/Expiry based on date range.
- Uploading of videos and storing them on our servers(or cloud)
- Define access control for the document
Open Items
One of the concerns is having to maintain all the edits as separate versions would result into very large table. A solution to reduce this would be to have just one draft version and store revisions of the published content. This means that a user can edit/reedit the same content again and again and as long as it is in draft, no version will be maintained. When the content is published, we store the published content as one version. Later on user can again edit/reedit the published content. When this changes are published, another version of the published content will be versioned. In other words the content that was published will be versioned.
Implementation
Table design
Table design
Table name - contents
| Column_name | type | Description |
|---|---|---|
| id | integer | primary key |
| title | varchar | Title of the content |
| raw_data | text | The actual content. |
| data | text | The actual content. without html |
| published_as | varchar | Current state. [draft, live] |
| user_id | integer | foreign key to the users table. User to whom the content belongs to |
| created_by_id | integer | foreign key to the users table. User who has created the content. Most of the times it will be same as user_id |
| updated_by_id | integer | foreign key to the users table. User who has last updated the content. |
| created_at | date_time | created date |
| updated_at | date_time | updated date |
Table name - content_versions
| Column_name | type | Description |
|---|---|---|
| id | integer | primary key |
| title | varchar | Title of the content |
| raw_data | text | The actual content. |
| data | text | The actual content. without html |
| published_as | varchar | Current state. [draft, live] (will always be live if we decide to store versions only of published content |
| user_id | integer | foreign key to the users table. User to whom the content belongs to |
| created_by_id | integer | foreign key to the users table. User who has created the content. Most of the times it will be same as user_id |
| updated_by_id | integer | foreign key to the users table. User who has last updated the content. |
| created_at | date_time | created date |
| updated_at | date_time | updated date |
| content_id | integer | foreign key to the contents table. Content to which this revision belongs to |
| number | integer | incremental revision number |
| live | boolean | Whether this revision is currently live or not |
- The contents table will store the latest version of the content. This can be in draft or live state. - The “content” once created, has to be published exclusively from the content listing page or show page. - The show page e.g user_id/contents/1 has link that will list all the previously published versions of that content. - There is an option in the version listing to revert to a specific version. Reverting back to a previously published version will copy the title, and data fields from content_versions to contents table. - All the public/published content can be seen by clicking on “Contents” tab in header (available only after login). - The autosave feature will be available in the edit mode and will keep saving the changes at the interval of every 10 seconds.
Embedding Image,Document and Video
To embed an image, the user uploads an image via the TinyMCE editor. Once uploaded the image gets processed by the ImageProcessor (to size the image ). Once processed, the image is embedded in side the document. (using an IMG tag)
Embedding Document - A document cannot be embedded to the content like an image as there is no specific html tag that can render a document. Because of this, a document needs to be converted to a swf file and an swf document viewer is needed to show/play this document.
To embed a document, the user uploades a document via the editor. The document processor, would process this uploaded ducument. First it converts the uploaded document to a dpf format. This is done using JodConverter (http://www.artofsolving.com/opensource/jodconverter). For JodConverter to convert the file, it requires headless OpenOffice/LibreOffice to be running. Once the document is converted to pdf, then the pdf file is passed on to the pdf2swf tool to convert it to swf format.
Note: JodConverter only converts files which has specific extensions (.txt, .doc, .odp, .xls, .ppt etc). If the file name does not have an extension then it fails to convert the document. To overcome this problem, if the file does not have an extension, then it gets renamed and .txt gets appended to its name. This file is then passed as input to the JodConverter.
The process for embedding a video is the same. The uploaded video gets converted to flv format using the ffmpeg converter.
