Modular Content

Introduction

In order to provide us better direction on the way the file directories are created and the way that objects and classes etc are created, I thought it would be good to have an outline of what kinds of content should be "modular," i.e. sharable via simple zip files through an "Exchange Interface" - ie what WordPress? currently uses in the back-end for Themes and Plugins.

Content That Should Be Modular

All the Modular content lives in the Library as a reference. These files are not modified when the site is running, instead they are copied and the copy is modified. This preserves the integrity of the source files without limiting people's creativity and customization.

All Modular content is linked to a central repository. Users can browse and install modular content through the back-end of the CMS, just like WordPress Plugins manager.

TOP LEVEL

Packages: Packages are complete, working web sites running on top of the CMS and designed to be portable. Packages have three critical uses:

Application Packages: Apps are OFFICIAL, SUPPORTED packages that define popular functionality, like Blogging or Forums.
Custom Packages: CPs are UNOFFICIAL, UNSUPPORTED packages that can be any kind of site. When you create a site from scratch you're effectively creating a Custom Package.

Restore Packages: RPs include all of the content of a custom or application package PLUS the content that resides in the database, so they act as a complete copy of an installed web site. These are primarily for backup purposes.
These Packages live inside a .zip file (or something like that) and are kept in the Library. When you create a new Site you're creating an INSTANCE of a Package.

If you "Export" your site you're creating a new "Custom Package" (does not include content).

If you "Archive" your site you're creating a new "Restore Package" (does include content).

For more see "What Is NOT Modular" below.

SECOND LEVEL

Extensions: Extensions add functionality to the core. They create new functions, new admin interfaces, etc.

Classes: Classes are prototypes for objects. When a CMS user wants to create a new object they can start from scratch (new class) or use an existing Class from the library. They can also start with an existing Class and change it.

Datatypes / Interpreters: A Datatype / Interpreter pair allows people to easily create useful objects from scratch. A datatype would be something like an Address (123 Main St. Somewhere USA 12345). The datatype is "Address" and the interpreter provides the instructions for how to create a form field to receive input for that datatype, validate the data that is entered, store the data in the database, and retrieve it as a useful object.

Datatypes/Interpreters are shared as a pair. Perhaps, logistically speaking, the "Interpreter" is the only file, but the useful function that an "Interpreter" adds is a new datatype that can be used for fields in an object.

What is NOT Modular

Instances: An instance is the actual working copy of a site.

For instance, if someone is running a specific installation of "Blog App", all the content files, customizations, and templates will live in the "site instance" directory.

If someone creates a new site from scratch using the CMS then a new "Site Instance" is created. There is no corresponding package until the user "exports" the site to make it a Custom Package or a Restore Package.

After export, changes in the Site Instance do not change the previously exported package - it is effectively a previous version. Sites can revert to a "Custom Package" without losing content as long as they do not have new dependencies in their current instance that were not present before.

Objects: Objects are the actual, implemented data structures running in a specific site. So if you have two sites on a network, and both of those sites use the class "Post", then one site will have something like "Site_1_Posts" as an object, and the other will have "Site_2_Posts" as an object.

Dependencies

Each type of modular content can include dependencies of the module beneath it, following this heirarchy:

Packages
Extensions
Classes
Interpreters
Templates & Themes
Templates are used to define a consistent structure for content to drop into.

Themes are cosmetic, non-structural changes to a template.

The "default appearance" of every Template could be considered it's "default theme."

So, for instance, you could have a "Photoblog Template" with a "Red Theme" and a "Blue Theme."

Templates are Dependent on Objects

In order for a template to successfully display content out of the database it has to know what the objects in use are called. In conventional blogging platforms, for instance, this is straightforward because the content is always something like "Posts" and "Pages."

In Palette, the goal is to have zero assumptions about what content types a site will use, so Templates are specific to a Package. There is no way for us to have a totally assumption-free content system and have templates that can work on any site.

However, for most users (who will run their site on top of a standard application package) there will be many Templates to choose from.