[ Rafael Oliveira ]:
|A não ser que eu tenha como requisito registrar todas as modificações
|nos objetos ...
Outra idéia que surgiu agora é usar Workflows como hook
Ou seja, em cada edição do objeto o Workflow é notificado
e scripts (before/after) podem ser usados para rastrear
as mudanças de
On 3/8/07, Rodrigo Senra [EMAIL PROTECTED] wrote:
[ Rafael Oliveira ]:
|A não ser que eu tenha como requisito registrar todas as modificações
|nos objetos ...
Outra idéia que surgiu agora é usar Workflows como hook
Ou seja, em cada edição do objeto o Workflow é notificado
e
|Rodrigo Senra:
|
| Acho que vc pode criar um mutator para o campo.
| O AT cria setters default para cada campo, mas estes
| podem ser sobrescritos por rotinas suas (bem como getters).
[ Rafael Oliveira ]:
|Essa solução funcionaria sim. Porém o meu cenário é um pouco pior (eu
|não deixei
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
Rafael Oliveira escreveu:
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.
[ Rafael Oliveira ]:
|Olá Rodrigo,
|
|obrigado pela dica, ela me levou a outras questões:
|
|1. Continuo achando estranho o método index_object() ser chamado várias
|vezes. Acabei de fazer um teste onde ele é chamado 20 vezes durante a
|criação de um objeto.
Eu já vi isso acontecer.
On 3/6/07, Rodrigo Senra [EMAIL PROTECTED] wrote:
[ Rafael Oliveira ]:
|2. A funcionalidade que eu procurava era de ter um gatilho ativado a
|cada vez que um campo de um objeto fosse alterado, mesmo que isso não
|acontecesse através da interface web. Por exemplo, se em algum lugar
|eu
