printable version
- email this article
View article without comments
Overview of SF-Active Concepts
by gek
Thursday, Dec. 23, 2004 at 9:20 AM
This is an overview of sf-active concepts so we can have a clear way of talking about things and planning for a 1.0 release.
SF-ACTIVE: Overview of Concepts
- Open Publishing Webcast System
The open publishing webcast system includes Webcast Articles, Webcast Comments and Webcast Media Files submitted by anonymous users.
- Webcast Articles
Webcast Articles are submitted to the Website by any anonymous user. At the minimum, a Webcast Article is a Title/Headline, Author, Summary and Body. In addition, a Webcast Article can include a Contact Email, Contact URL, Contact Address, Contact Phone. Webcast Articles are never deleted from the database but they can be toggled to Hidden Status to prevent them from being used on the Website. Webcast Articles are stored in the webcast and webcast_text tables. A Webcast Article can be linked to a Language. A Webcast Article can be linked to any number of Categories.
- Webcast Comments
Webcast Comments are submitted to the Website by any anonymous user and must have a Webcast Article parent. At the minimum, a Webcast Article is a Title/Headline, Author, Summary and Body. In addition, a Webcast Article can include a Contact Email, Contact URL, Contact Address, Contact Phone. Webcast Articles are never deleted from the database but they can be toggled to Hidden Status to prevent them from being used on the Website. Webcast Comments are stored in the webcast_comment and webcast_comment_text tables. A Webcast Comment can be linked to a Language. A Webcast Comment inherits the Category of its parent.
- Webcast Media Files
Webcast Media Files are submitted to the Website by any anonymous user and must have either a Webcast Article or Webcast Comment parent. Webcast Media Files are an Author, Description, Filename and Mime Type. The record of the file is stored in the webcast_media table and the actual file is stored on the filesystem. A Webcast Media File inherits the Category of its parent.
- Editorial Publishing System
The editorial publishing system includes tools for organizing and creating content by privileged, password-protected users. There are two peacefully-coexisting systems which make up the editorial publishing system: Category-Based Editing (the traditional way) and Page-Based Editing (the new SF CMS code).
- Category-Based Editing
Category-Based Editing is the traditional way that sf-active content is managed. The central concept of this system is the Category which has Center Column and Newswire properties. These different elements come together to create a formulaic "category page" which can be cached to disk.
- Categories
Categories are site-wide and can be used to classify a number of sf-active objects. In the Category-Based Editing system, they are the central concept for content management. Categories are a Short Description, a Long Description, a Newswire Type, a Newswire Length and a Center Column. Categories are further classified by "Category Class". The system will cache a standard format (plus template) page for any category which includes the Center Column and Newswire. Categories are stored in the category table.
- Center Columns
A Center Column is a property of a Category (in addition to a special site default category). A Center Column is a collection of Blurbs (or Stories) that can be sequentially ordered one after another. A Blurb is a Short Title, Long Title, Optional Image and Summary. In addition, Blurbs can be Hidden or Archived. Each Center Column and Blurb is tied to a template for customization. Blurbs are stored in the feature table.
- Newswires
Each Category can also have one newswire which is a chronological list of Webcast Articles linked to the Category. The Newswire for a Category can be Standard (all Webcast Articles), Filtered (all Webcast Articles subdivided into Local, Global and Open) and Entire (unknown!). Newswires can use a template for customization.
- Limitations on Other Content Management
Aside from the Category Pages, other pages on the website can only be partially managed through the Category-Based Editing system. Style Sheets, various include files, templates and "process pages" can be edited via a web-based text editor. Anything beyond this level of management must be performed outside of the web-based administration system (requiring direct access to the Unix system where the site is hosted).
- Page-Based Editing (New SF Code)
Page-Based Editing is the new system under development to allow full content management of all pages and complete mirroring of the entire website using database replication. The central concept of this system is the Page -- representing any page accessible to a visitor to the website.
- Website Pages
A Page is a record in the database as well as a cached file in the web document root. Properties of a Page are Nickname, Description, Width, Header, Footer, and Filename. Each Page also has a Page Structure and Page Layout. Content managers can use visual tools to place customizable Widgets within the Structure of a Page. Pages are stored in the newsroom_pages table.
- Page Structure
A Page Structure is defined using Rows, Columns and Matrices to create Cells on the page. Once a Page Structure is created, it generally does not have to be edited again. Once the Structure for a Page is defined, content managers can place Widgets on the Page. Page Structures are stored in the newsroom_cells, newsroom_matrix and newsroom_spaces tables.
- Widgets
Widgets are customizable objects which can be placed in any valid Cell on a Page. Widgets are self-contained bits of code, designed to make it easy to create and add new ones to the system. Examples of Widgets which already exist include Newswires, Pictures, Raw HTML, Text Blurbs and Indymedia City List.
- Examples
To create the equivalent of a "Category Page" from the Category-Based Editing system, a content manager would create a new Page, define its Structure, place a Newswire Widget (customizing the newswire length, newswire category and other properties) on the page, and then place Text Blurbs around the page. Using the Page-Based Editing System, the content manager has more control over the entire page layout instead of being restricted to a formulaic Left Column/Center Column/Newswire layout.
- Advantages
With the Page-Based Editing System, all include files can be eliminated from the filesystem -- this HTML would now be stored in the database and placed into a Page Cell as a Widget. All Pages on the site can be edited through the web-based administration in a standard way. All Pages on the site (including their layout, content, etc) are stored in the database and can be mirrored via standard MySQL replication. New and exciting ways of formatting Indymedia sites can be turned into a Widget and widely reused in a standard way. In addition, this system adds WYSIWYG visual editing tools which can be expanded using Java text editors, etc to enhance the application.
- Caching & Mirroring
An essential component of sf-active is to cache to disk as much as possible (towards a goal of entirely caching all pages on the site for mirroring). Currently, we have Mixed Caching while the goal is to have Complete Static Caching.
- Mixed Caching (Current System)
Currently, sf-active caches certain elements of the site: Center Columns, Newswires, Webcast Articles. It then uses logical PHP include()'s to build a page when it is requested by the web server. While this improves the speed of the site, it does not allow for easy mirroring of static HTML pages.
- Complete Static Caching
We should have the ability to completely store all content in the database for all pages on the site and be able to completely reconstruct the website from this data. This does exclude Webcast Media Files or other uploaded media files, which must be rsync'ed to be mirrored. In addition, Complete Static Cachine requires solutions for cookie-based features of sf-active, including language preference and CSS theme. Sites which use Page-Based Editing will be close to having all content stored in the database with the ability to generate static HTML files.
- Mirroring
In order to mirror and have distributed serving of a given site, we should add several layers of sf-active site installations. The Master Site (bound to a given domain name, i.e. publish.sf.indymedia.org) is where open publishing and site administration takes place, with inserts/reads allowed on the database. Any number of Replicated Sites can exist which have replicated instances of the Master Database with read-only access allowed. On a scheduled basis, Replicated Sites receive updates from the Master DB and re-cache their pages accordingly. This means that the Replicated Site server will be doing a lot of work all the time. The third type of server would be the Mirrored Site which only hosts the Static HTML and media files. This type of server could all be set up using rsync.
|