[Openinteract-dev] Mapping observers in packages

[Antti Vähäkotamäki]

Chris,

I couldn't get my observers working when defined in package's
package.ini like this:

[package observer]
myobs = OI2::...

[package map]
myobs = someaction

And then noticed that observer _mappings_ defined in packages are not
applied at all.

Is there some reason for this or would you accept a patch to apply also
mappings from packages' package.inis?

- Antti

[Chris Winters]

Post by Antti Vähäkotamäki
...
And then noticed that observer _mappings_ defined in packages are not
applied at all.
Is there some reason for this or would you accept a patch to apply also
mappings from packages' package.inis?

I think it's just because I never thought of it :-) Patches (or
commits) would be great. (I assume you're initializing the map in
OI2::Observer->initialize()?) Just one note: I'd name it
'observer_map' instead of 'map' in the package.ini just to eliminate
ambiguity.

Chris

[Antti Vähäkotamäki]

Post by Chris Winters
I think it's just because I never thought of it :-) Patches (or
commits) would be great. (I assume you're initializing the map in
OI2::Observer->initialize()?) Just one note: I'd name it
'observer_map' instead of 'map' in the package.ini just to eliminate
ambiguity.

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>."

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.

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..).

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)

Should I do this instead / also?

- Antti

PS. For what purpose would one need the global observer.ini if you can
define observers and mappings in packages?

[Chris Winters]

Post by Antti Vähäkotamäki
You have even commented it this way so I thought you might have some
"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 clarity.

Post by Antti Vähäkotamäki
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.

Post by Antti Vähäkotamäki
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.

Post by Antti Vähäkotamäki
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.

Post by Antti Vähäkotamäki
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).

Post by Antti Vähäkotamäki
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

[Antti Vähäkotamäki]

Post by Chris Winters
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)

Post by Chris Winters
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.

Post by Chris Winters
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.

Post by Chris Winters
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