Use seu ambiente de edição favorito

Nunca subestime a importância disso. Eu uso vim, que sobe rapidamente (somente ele pode ser usado fàcilmente com ExternalEditor TTW), e que praticamente já está instalado em todo servidor(assim eu posso usa-lo através do ssh). Entretanto, sempre considerando isso, eu próprio o achei quase duas vezes mais produtivo, podendo trabalhar em meu ideal ambiente de edição, com minhas macros, scripts, caminhos, etc., já configurados.

Uma palavra: o grep!

grep e find são os “enviados de DEUS” para trabalhar no sistema de arquivos. Uma vez que você acostumou-se com ele, após anos usando a ZMI, você a ignorará e pensará que ele é uma maravilha.

Gerenciamento do código fonte

Você pode usar suas ferramentas de gerência usuais do código de fonte.

Estagiamento/replicação

Ele é fácil de replicar sua configuração para múltiplas instâncias.

Objetivo: Nenhum skin ou script no ZODB. Somente o resultado das configurações  e o conteúdo

Seu objetivo final será o de que o ZODB tenha somente os objetos de seu conteúdo e os dados da configuração feitos por scripts. Todas nossas skins e todos nossos scripts estarão no sistema de arquivos.

Às vezes, ele é muito útil por guardar scripts ou skins. Por exemplo, você pôde ter um logo diferente em partes diferentes de seu site, e uma prática comum do Zope para isto deveria ser: Ter logo.jpg na raiz de seu site, e um diferente em /about. Entretanto, isto deixa uma parte da skin no site, e prejudica nossa possibilidade de mantê-la bem. Melhor é ter na pasta raiz e na pasta /about  uma propriedade -- palavra, o nome do logo, que nos diz que logo a se usar nesta área. Então, nós podemos manter todos estes logos no sistema de arquivos, e conseguimos nosso objetivo apenas de manter a parte de configuração no ZODB.

Adicionando novo conteúdo armazenado no sistema de arquivos

Siga os exemplos dos tipos de conteúdo dentro CMFPlone

No CMFPlone, há uns exemplos de todos os tipos que podem ser armazenados no sistema de arquivos incluindo features como configuração do proxy, títulos, configurações de segurança. grep é seu amigo aqui: grep - r -- include="*.metadata" o proxy *  e dará a você um exemplo de como usar os arquivos .metadata para configurar um proxy. Este não é um exemplo de ZSQLMethod enviado com CMFPlone, CMFDefault, ou CMFPlone. Para uma discussão de ZSQLMethods e um exemplo de um ZSQLMethod armazenado no sistema de arquivos, veja http://plone.org/Members/pupq/reldb.

Arquivos .metadata para arquivos, segurança e regras de proxy

Estes são arquivos que acompanham anexos todo e "qualquer material”; para objetos, títulos, configurações de segurança, regras de proxy para scripts Python, e mais. Estes substituem os arquivos de propriedades em umas versões mais adiantadas do CMF. Um erro comum é customizar um arquivo de objeto skin (palavra, foo.py) pela copia para um diretório novo, mas não copiando algum foo.py.metadata. Note que o arquivo .metadata deve estar no mesmo diretório, Assim, neste caso, o objeto customizado do foo é usado, e não inicias as configurações no arquivo metadata. Se isto contivesse coisas importantes, como configurações de segurança ou do proxy, isto poderia ser desastroso.

Modo Debug e Conteúdo Armazenado no Sistema de Arquivos

No modo debug, mudanças para armazenamento de conteúdo no sistema de arquivos são vistos imediatamente. Se você não está no modo debug, você terá que ou reiniciar o servidor de Zope ou fazer um refresh do produto usado. Note que se você está usando SpeedPack abaixo do modo debug, você deverá ver mudanças nos objetos da skin, por tanto tempo que eles não serão copiados de um diretório a outro. Entretanto, se você customizar um objeto da skin para um diretório novo e estiver funcionando SpeedPack abaixo do modo debug, Zope já fará cache da posição velha do objeto skin, e não usará a posição da nova versão. Reinicie ou faça refresh do produto usado para ter a informação de Zope sobre isto.

Exemplo de arquivo metadata

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

Armazenamento de novos tipos em sistema de arquivos

Isto é possível para criar seus próprios tipos armazenados em sistema de arquivos. Se houver uns objetos que de não-conteúdo que você usa frequentemente, é importante criar um pequeno script que permitirá que seja armazenado no sistema de arquivos. Você pode olhar o código em CMFCore para armazenar os tipos existentes (Modelos de Páginas, Scripts Python, Arquivos, etc..) Um exemplo disso é FSExternalMethod. Isto é examinar um tipo de objeto existente no Zope e criar uma versão dele capaz de armazenar no sistema de arquivos. Procure no produto "FileSystemSite".

Compensação de corrupções no sistema de arquivo

Algumas vezes não é possível trabalhar no sistema de arquivos. Você pode somente ter o acesso por um navegador web ou ter criado muitos objetos na skin existente no ZODB. FSDump fará exame dos objetos existentes da skin e irá removê-los do sistema de arquivos.

FSDump: 

Dumps do material existente no ZODB para o sistema de arquivos

Você necessita escrever dumps para seus tipos armazenados no sistema de arquivos.

Se você escrever tipos customizados para armazenamento no sistema de arquivos, você terá que escrever seu próprio plug-in do dump para esto. Isto é completamente fácil de fazer -- veja o código em FSDump para exemplos de como são os tipos básicos de dump.

Muito menos - use FSDump para backups