Forum OpenACS Development: Re: .LRN callback for member approval

Collapse
Posted by Dave Bauer on
I agree with Don's analysis. Its quite likely that dotlrn does not call the particular generic API to change the member state (I have not checked), but putting the callback in the most general place, and refactoring the code to use the general API is a better design.

Callbacks should go were they can be most useful and reused, that is, in exactly the type of procedures that should be reused in many places.

Collapse
Posted by Malte Sussdorff on
"Callbacks should go were they can be most useful and reused, that is, in exactly the type of procedures that should be reused in many places."

Which also means the implementations are called in many places. So in my specific case, my custom callback would be called on each change of status of a relationship, of which we have quite some in OpenACS.

Limiting the calls using the implementation does not work though as we cannot limit ourself to say "we only allow one callback per type". This has proven to be desaster in the implementation attempt for incoming e-mail callbacks in acs-mail-lite (in case you have been thinking about calling the implementation as the type of the relationship, e.g. dotlrn_membership_rel).

If you suggest to enforce a naming conventions for callbacks though, e.g. "$type_< your_imp_name>", I am not sure if you can call all callbacks whose implementation starts with $type.

That is, if you are concerned with the number of calls to the callback in the first place.