(Review this for UX considerations) Proposal to specifically support file system templates

[peakpg]

Imported from lighthouse. Original ticket at: http://browsermedia.lighthouseapp.com/projects/28481/tickets/155. Created by buzzware - 2009-09-12 16:53:14 UTC

I would like to have a go at suggesting a scheme for specifically supporting file system templates.
I have almost completed a scheme for achieving the same goals with 3.0.1, though it involves running
a shell script after bcms has done its copy to tmp.

My goals are :

• to provide a nicely integrate designer/developer workflow, where designers can work on templates in an environment they are used to ie ftp access to files
• to keep the content seen when the customer logs in 'clean' ie only content that they are free to touch. so no templates in the database.
• to allow version control and capistrano deployment of the cms itself, plus additional customisation code, assets etc

My approach so far is :

• have a design folder in the capsitrano shared folder, that doesn't get stomped on redeploy
• inside that, have a templates folder (should this be views ?) and another design folder (shared/design/design) for assets
• essentially serve shared/design via FTP (not quite true - I'm using pureftpd's virtual chroot feature)
• symlink design/design as public/design, so the designer can ftp files into the design folder, and refer to them under /design in their urls.
• in an initializer, I call a shell script that copies the contents of the templates folder in /tmp (from the db) to shared/design/templates and makes them readonly to prevent the designer changing them. It also does the same with any files in app/views/layouts/templates (my developer filesystem templates). It then replaces the tmp templates folder with a symlink to shared/design/templates.

In summary, the served templates folder is a combination of database, developer filesystem, and designer filesystem templates.

To make this a standard feature, may I suggest :

• bcms support a configurable folder path for templates, and expects there to be templates there that it doesn't control, but will allow selection of them in the admin area (like now)
• the template folder needs to be served live, not copied, so that designers can change their templates and see the result on the fly. This may have implications for caching, but I would think that the fully rendered pages are cached, not the templates ?
• when it renders its db to the filesystem, it copies the contents of app/views/layouts/templates too
• optionally, when templates are copied in, they are made read only.