On 07 Mar 2007 07:16:38 -0800, Rodrigo Senra <[EMAIL PROTECTED]> wrote: > > |Rodrigo Senra: > > Só no momento da criação, ou em qualquer atualização de campo ? > Pelo que vc disse, me parece ser a segunda opção, ou seja > um hook em qualquer atualização de campo.
É isso mesmo ! > Uma das lições aprendidas com isso (ainda que não fosse aplicado a > PZP) é que hooks em *tudo* são os assassinos do desempenho. > Por isso tome bastante cuidado, em geral hooks devem ser colocados > em *poucos* objetos e mediante uma escolha cuidadosa de onde colocar. A não ser que eu tenha como requisito registrar todas as modificações nos objetos ... > Feita essa advertência, uma forma seria no at_post_create_script() > da classe Base (da qual todos seus tipos herdam) vc coloca um > código reflexivo que inspeciona os campos (percorrendo o atributo > schema) e troca os getters/setters por wrappers que chamam o seu > método de hook (em pré-chain ou pós-chain) e chamam também o > getter/setter original. Não é trivial, mas também não é nada > do outro mundo. É uma idéia interessante. Obrigado pela dica. > > É preciso ter dois cuidados: > > 1) evitar recursão infinita - de dentro do hook, se vc tentar > (...) > 2) O outro cuidado é não causar efeitos colaterais com os encantamentos > do AT, CMF, ExtensionClass do Zope. Ok ! > |A primeira coisa que me veio a cabeça > |foi sobrescrever o __getattr__() das classes para interceptar as > |chamadas dos setters de todos os campos > > Acho que *não* vai funcionar, pois o __getattr__ só é chamado se > os atributos *não estiverem previamente definidos*. Ou seja, só > funciona para atributos virtuais. Nessa linha seria melhor > usar __getattribute__, que é chamado até mesmo para atributos > *já definidos*. Isso eu não sabia. > Todavia, esta estratégia recai no problem de > "interceptar tudo" -> vai ficar uma carroça-de-boi-manco e vai > ser difícil escrever o código do hook. > Mas, se vc quiser ir por essa linha eu ficaria *contente* > se vc me provasse que eu estou errado a este respeito. > Toda a comunidade ganharia com isso. Infelizmente eu não poderei testar nenhuma das soluções agora, porém eu concordo que a solução que eu pensei inicialmente deve ser meio complicada de implementar. A sua solução envolve menos magia negra do Python :D []s > > Abração, > Senra > > ------------- > Rodrigo Senra > GPr Sistemas > http://www.gpr.com.br -- Rafael Bruno Cavalhero de Oliveira <[EMAIL PROTECTED]> Paradigma <http://www.paradigma.com.br> http://rafaelbco.wordpress.com
