These are some Use Cases that guide Bright Content's design
Lightweight CMS
See also: Bright_Content/CMS
Web sites driven by a certain amount of content reuse, so that static pages are cumbersome.
Bright Content's CMS module sets up 3 main logical areas:
- rendered
- general interface used by readers
- admin
- generally requires authentication (usually OpenID). Allows for CRUD of and other management of pages to be rendered. Also generally the basis of public "APIs", so to speak, for BC-driven Web apps
- raw
- provides access to unprocessed source files for rendered content. Also generally the basis of public "APIs", so to speak, for BC-driven Web apps
An administrator can seed the site by specifying a root page, e.g. http://example.org/. Following are three approaches:
"Create new page" from admin, and enter it as Wiki text, or some other specified format. Designate the page as the document for "/", using the special annotation bc:publish-destination with value /
Upload an XML file, including a stylesheet processing instruction, register XForms for updating it, using the special annotation bc:content-update-form with the path to the form. Designate the file as the document for "/", using the special annotation bc:publish-destination with value / (no need to specify path to the template).
Upload an XML file, register XForms for updating it, using the special annotation bc:content-update-form with the path to the form. Designate the file as the document for "/", using the special annotation bc:publish-destination with tuple value / and the path to the template.
Weblog
See also: Bright Content/Weblog
Bright Content should, out of the box, support the basic, common features of Weblogs, including:
- Standard view of recent entries, including date-based URL access
- Atom feeds
- Templates
- Other feeds such as RSS x.x (through bundled plug-ins)
- Entry archives (through a bundled plug-in)
- Comments (through a bundled plug-in)
Some less common features that Bright Content should support are:
- Basic APP support
- Multiple Weblogs instances - you should be able to host multiple Weblogs on one Bright Content server instance
- Entry re-purposing - you should be able to have an entry from one Weblog instance syndicated to other Weblog instances, even if the others are not on Bright Content (they do have to at least support APP POST, by default). An example is if you have a personal and a work Weblog, and you post all entries to your personal Weblog and want entries with a "work" tag to be automatically posted to your work Weblog as well.
- Simple rich metadata and semantic technology features (e.g. tag roll-up)