Working off the file system

Use your favorite editing environment

Don't underestimate the value of this. I use vim, which launches
quickly (so it can be used easily with ExternalEditor TTW), and
which practically every server already has installed (so I can use
through ssh). However, even considering that, I find myself almost
twice as productive being able to work in my exact editing
environment, with my macros, scripts, paths, etc., already set.

One word: *grep*!

grep and find are the godsends of working on the filesystem. Once
you've reacquainted yourself with them after years of ignoring them
for the ZMI, you'll wonder what you were thinking.

Source code management

You can use your usual source code management tools.

Staging/replication

It is easy to replicate your setup across multiple instances.

Goal: no skins or scripts in ZODB. Only config results and content.

Our end goal is that the only thing in the ZODB will be
our actual content objects and configuration settings made by
scripts. All of our skins and all of our scripts will be on the
filesystem.

Sometimes, it's very helpful to have scripts or skins be placeful.
For example, you might have a different logo in different parts
of your site, and a common Zope practice for this would be to have
'logo.jpg' in the root of your site, and a different one in
'/about'. However, this leaves a piece of skin in the site, and
ruins our ability to maintain it well. Better is to have the root
folder and '/about' folder have a property--say, logo_name, which
tells us what logo to use in this area. Then, we can keep all of
these logos on the filesystem, and have achieved our goal of just
keeping the configuration part in the ZODB.


Adding New FS-Stored Content

Follow the examples of content types in CMFPlone.

In CMFPlone, there are examples of all of the types that can be
stored on the filesystem including feature like proxy settings,
titles, security settings. 'grep' is your friend here: 'grep -r
--include="*.metadata" proxy *' Will give you an example of using a
proxy setting in .metadata files.

There's no example of a working ZSQLMethod shipped with
CMFPlone, CMFDefault, or CMFPlone. For a discussion of ZSQLMethods
and an example of a filesystem-stored ZSQLMethod, see http://joelburton.com/resources/reldb.pdf.

'.metadata' files for title, security, proxy roles

These are the accompanying files that hold all the "other stuff" for objects,
titles, security settings, proxy roles for PythonScripts, and more.
These replace the .properties files in earlier versions of the CMF.

One common mistake is to customize a skin object file (say,
'foo.py') by copying it to a new directory, but not copying any
'foo.py.metadata'. Note that the .metadata file **must** be in the
same directory, so in this case, the customized foo object is used,
and it does not get the settings in its metadata file. If this
contained important things, like security or proxy settings, this
could be disastrous.

Debug mode and FS-stored content

In debug mode, changes to filesystem-stored content are seen
immediately. If you're not in debug mode, you'll have to either
restart the Zope server or use product refresh.

Note that if you're using SpeedPack under debug mode, you'll see
changes to skin objects, as long as they don't get copied from one
directory to another. However, if you customize a skin object to a
new directory and are running SpeedPack under debug mode, Zope has
already cached the old location of the skin object, and won't use
the new location version. Restart or use product refresh to have
Zope notice this.

Metadata File Example

From 'register.cpy.metadata' ::

[default]
title=Register a User
proxy=Manager,Anonymous

[validators]
validators = validate_registration

[actions]
action.failure=traverse_to:string:join_form
action.success=traverse_to:string:registered
action.prefs=traverse_to:string:prefs_users_overview



New FS-Stored Types

It is possible to create your own FS-stored types. If there are non-contentish objects you use often, it's worthwhile
creating the small script that will allow it to be stored on the
filesystem. You can look at the code in CMFCore for storing the
existing types (PageTemplates, PythonScripts, Files, etc.)

An example of this is 'FSExternalMethod'. It is taking an existing Zope object type and creating a
FS-stored capable version of it. Found in the product "FileSystemSite".


Atonement for Your Sins - FSDump

Sometimes, it's not possible to work on the filesystem. You may
only have access to a web browser or have created many existing skin
objects in the ZODB. FSDump will take existing
skin objects and dump them out to the filesystem.

FSDump:

* Dumps existing ZODB stuff to FS

* You need to write dumpers for your FS-Stored types.

If you've written custom FS-stored types, you'll have to write
your own Dump plug-in for this. This is quite easy to do--see the
code in FSDump for examples of how it dumps the basic types.

At the very least — use FSDump for backups