biv / cms_foo

Plan.

Write CMS code last (the easy bit). Step through integration examples first and mock CMS responses.

Use cases (clients):

* html decorator - simplest use case, a web app. proxies calls for pages to the CMS and decorates the HTML fragment 
within its own display layer.



* proxies calls to the CMS for HTML fragment, which is placed on the page. Application authentication occurs.
* proxies calls to the CMS for Folder and its contents, which it decides how to display (think 'send to friend' 
workflow).
* folds the administration system of the remote Rails app. into its own backend. (user integration or SSO)



Just hacking some ideas for a CMS.

Notes


Premise:

Know what problems not to solve when writing a CMS, in their absence find easier ones. A dumb CMS.

Separation of Concerns
----------------------
Logical division of applications (though could share same DB, probably use Rack middleware).

Front application - CMS.

Other app.s where building logic outside of a CMS  but being able to call on the CMS easily is desirable.
structured forms (e.g. STF) - reuse of CMS
complex workflows


Leverage of Functionality
-------------------------
Administration - admin. templates should be able to be reused in the hosting app..

Restful behaviour will ensure integration. User accounts and privileges should be integrated somehow (not hard).

CMS.
Conceived as a service, rather than an inclusive complex system.

Folder - FolderEntry (subclassable) - Page

To add a new CMS type for folders, e.g. attachment, you AttachmentFolderEntry < FolderEntry, and Attachment belongs_to 
AttachmentFolderEntry through a polymorphic association.

All Folder entries can be ordered easily on their folder.


Roles - guest, member, admin. (roles can be made)

Each Folder has CRUD assignments to roles - so R for guest, member, admin, is accessible content for everyone. If it's D 
for admins, only admins can delete what is in that folder. These rules define all access across the application, at the 
front and the back cms admin area (e.g. if a content editor role is invented, and a content editor wants to edit a page 
in the CMS admin, only pages in folders with RU will be presented in the controller).


Alpha version:

Folder, page, users and roles, admin system integrated across.


How do they integrate?
----------------------
Content:

All content is restful and is served to other app.s is security is satisfied. The format of the request is either html 
or xml.

For generic content inclusion a standard CMS fetcher account should be used. This should be separate to the admin 
account.


Users:
Not sure yet. Users in the front application will have their own models and security rules.


Paging?


Further ideas
-------------
It would be great to have a generator which the front app. could call to produce admin. UIs.

There's no reason why a CMS instance couldn't service a number of sites, each with a different folder hierarchy.





Sancho CMS is named after Don Quixote's sidekick - Sancho Panza http://en.wikipedia.org/wiki/Sancho_Panza .