This repository is private.
All pages are served over SSL and all pushing and pulling is done over SSH.
No one may fork, clone, or view it unless they are added as a member.
Every repository with this icon (
) is private.
Every repository with this icon (
This repository is public.
Anyone may fork, clone, or view it.
Every repository with this icon (
) is public.
Every repository with this icon (
cms_foo /
README
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 .








