From: <an...@io...> - 2006-01-15 18:08:03
|
Chris Winters wrote: > True, but I'm not sure why a package would want to eliminate observers. I meant that you can't use global configuration to eliminate observer mappings issued in packages. (Like action-override.ini and spops-override.ini do for actions and objects) > I think using object/subroutine observers is a mistake: it just adds > more syntax for very little gain, since class-based observers should > be generic enough for everyone. I agree. > I don't think so. Adding the 'observer_map' section to the package > should be sufficient, and adding yet another configuration file should > be something we do only if we absolutely have to. It just feels odd that this kind of functionality is defined in package.ini (which doesn't end up even in the websites conf-directory), but i'll do the observer_map and leave it at that for now. > I can see the package-level observers being useful to implement > application functionality without the end user having to know about > it, but global observers being useful to apply common rules to many > different objects without those objects knowing it. This brings up the question - should we make a similiar easy way to attach observers to objects of some type? I think the only way to attach "triggers" to objects from other packages (or from the same package without modifying the object) is to use global spops-override.ini and manipulate ISA. For example if I would like to do something each time a user object (from package base_user, without using global overrides) is removed, I would now have to modify each location in the code where a remove is issued to notify observers and then map my observer to all the actions doing some user deleting. Would separate 'observe_action' and 'observe_object' be a good approach? - Antti |