On 1/15/06, Antti V=E4h=E4kotam=E4ki <an...@io...> wrote:
> You have even commented it this way so I thought you might have some
> good reason:
>
> "Mapping an observer to an action is exclusively done in
> C<$WEBSITE_DIR/conf/observer.ini>."
I can't think of the reason; hopefully I just added that comment for clarit=
y.
> One reason I thought up when doing that change was that you can not
> disable those mappings in any way from the global configuration - you
> can just add more mappings.
True, but I'm not sure why a package would want to eliminate observers.
> Also I noticed that because package.ini requires the package-namespace
> to be used, you can not define object- or subroutine-based observers -
> only class observers (I don't need them, but still..).
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.
> Would it be better to let packages just define their own
> conf/observer.ini files? (If the need arises, they can then be made
> overridable by observer-override.ini)
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.
> Should I do this instead / also?
Sure, go right ahead! I have very few cycles to devote to this right
now (perils of having an interesting day job).
> PS. For what purpose would one need the global observer.ini if you can
> define observers and mappings in packages?
A very useful aspect of an observer is that it can be applied by the
end user, and I think the end user is much more likely to read/modify
global configuration files than package-level configuration files.
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.
Chris
|
