Concave, a Simple CMS

Get Started. It's Free
or sign up with your email address
Rocket clouds
Concave, a Simple CMS by Mind Map: Concave, a Simple CMS

1. Content Types System

1.1. Based on plone's dexterity infrastructure

1.1.1. Export Dexterity schemata

1.2. Few builtin types

1.2.1. Web page Folderish Fields Title field Rich description field Rich text field Viewlets List and link children (basic folder listing) Behaviors Change default view

1.2.2. Alias/Link Provides a few behaviors 301 redirect to an arbitrary URL Exact duplication and redisplay of an arbitrary content object (to make it easy to have one content object appear at multiple URLs/folders) Serving of any browser view

2. Create revision

2.1. If we have working-copy support, you'd create revisions

3. Plugin points

3.1. Search

3.1.1. Concave will not provide search out of the box, but will fire events when content is changed so that the content can be indexed

3.2. Static file support

3.2.1. Convex should provide a "file" type that it actually manages

3.3. New content type fields

3.4. New Content Types

3.5. Templates for existing types

3.6. Directories of templates

4. UI System

4.1. Site theme provided by deliverance/middleware

4.2. Inner-pages composed of viewlet

4.2.1. Block system for blocks of cross-page or reusable content This could be promo portlets This could also be auto-generated navigation

4.2.2. Query-based blocks This could be how we implement folder listings, file directories, and even eventually a Plone-collection-like system Query types Content objects by path Content objects by metadata

4.2.3. content-display for any given content type is a viewlet associated with that type This implies when you add a new object of type X, it's some sort of generic "page" that has that type's viewlet display associated with that page by default

4.3. Ability to register new templates through the filesystem for existing content types

4.3.1. We should have a paster template for this


4.4.1. Nearly is a viewlet

4.4.2. Page templates are templates of DIVs that contain various types of orderable viewlet managers

4.4.3. Webpage is a generic object that can have a template associated and a type associated When you create a new page, you pick which type it will contain The type you pick for the page determines (1) the default layout picked for the page and (2) a viewlet that goes in the manager named "main," which any template must provide Pages can be created without a type, in which case they are "landing" pages and just display viewlets, or alias pages, in which case they can have a viewlet associated with any type in the main area and they will refer to that other content object for content

5. Questions

5.1. Do we have roles?

5.1.1. E.g., Editor, manager, public

5.2. Do we bother to support per-user customized content

5.2.1. I'd say, no

5.3. Do public (non-content-managing) users ever log in?

5.3.1. I'd say no. If you want some sort of collaborative site, use Plone.

5.4. How do we support commenting? Could we just use Disqus and export later?

6. Workflow Support

6.1. hurry.workflow integrated with authorization

6.1.1. Authorization is simple: private, public, editable or not

6.2. Simple working copy support for editing documents

6.2.1. Is this worth the effort? It's not a bad idea.

7. Import/export support

7.1. Exporters

7.1.1. Plone GSXML content

7.1.2. HTML content If all content types can fulfill some sort of IContentPaths interface that exports a list of valid URLs to all content of that type, we could use urllib to just "scrape" the whole site

7.2. Importers

7.2.1. HTML scraper It'd be neat if we could write a rule-based HTML scraper that could spider a bunch of pages and re-create them in concave

7.2.2. Wordpress/Moveable Type importer These have defined export formats that shouldn't be too hard to import as pages

7.2.3. Database Walker Describe, declaratively how to look at some RDB and import its content as pages for systems like Tyop3 and Drupal

7.2.4. Arbitrary data-source importer RSS Flickr

8. Design notes

8.1. Ship with a set of paster templates for creating new skins, content types, and other stuff

8.2. UI Components should be able to tell you where they live on the filesystem

8.3. Connecting a view class to a template should be done through filenaming and directories, over-rideable in the python

9. Filesystem pages

9.1. Provide base-classes for creating sets of file-system pages that are written in ZPT/chameleon and served straight off the file system

9.1.1. Providing the URL exporter for these will be hard

9.1.2. We can use megrok.trails

10. Nonsexy, basic CMS stuff

10.1. Cut, Copy, Paste, Move, Delete

10.2. Undo support

10.2.1. Do we actually care about this?

11. Attractive Future Plugins

11.1. Public content

11.1.1. Allow content types that can be submitted by anon users and workflowed

11.2. Admin UI

11.2.1. Make it easy to browse and manage sets of content, such as public content

11.3. Incoming Feeds

11.3.1. Imports content through the arbitrary data-source importer

11.3.2. Provides a feed-display viewlet

11.3.3. Provides a feed folder that is where you configure that Creates content objects for feed, if that's useful Items can be workflowed if that's useful (for approval)

11.3.4. Provides a many-feed display viewlet This basically aggregates the results of a bunch of feed folders

12. Syndication system

12.1. It should be relatively easy to define an RSS feed for pretty much any collection of content.

12.2. Webpages should have automatic feeds for themselves

13. The ends of our use cases

13.1. Sophisticated workflow support

13.1.1. Review by voting

13.1.2. Group or role-based user content access

13.2. Through-the-web page compositing

13.3. Through the web forms

13.4. Real collaborative content authorship and maintenance

13.5. Custom content based on user role or group