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

Posted by Don Baccus on
If we're to have such a callback I'd prefer one callback for any state change, rather than a specific callback for the change of state to "approved".

And instead of putting it where you've suggested, I'd suggest the "change_state" proc inside acs-tcl/tcl/membership-rel-procs.tcl.

My preference is for a minimum of callbacks generalized to be as useful as possible, rather than creating a single specific callback for a particular need you have at a particular moment.

Posted by Malte Sussdorff on
Don, the point is simple. Having such a generic callback will make it much harder to use the callbacks and, more to the point, will make it even less obvious to the developers. I mean, how many functional levels in an API does the developer drill down to if he is to use the API.

Going with your suggestion would mean, that a developer who wants to make an extension as I need it, to look at this procedure, look at the underlying procedures, and find the callback. Once done, he needs to write some code, which, given a rel_id will look:

- is this rel_id present in dotlrn_member_rels_full for every relationship change in a relationship within the system.
- if it is a rel_id that belongs to a dotlrn_member_rel, get the community_id and the user_id.

For me the fundamental issue is, if we are supposed to drill down to the lowest sensible level when adding callbacks, it will make it much harder to read the code and will cause detecting side effects much more difficult. This is why I would limit the scope of a callback and have many of them instead of having a large scope for a callback but just a few.