Rob Crittenden wrote:
Pavel Zůna wrote:
This is somewhat of a tech-preview patch. It works, but the whole
concept might need some more work/thinking done.
It adds another way to extend plugins without resorting to the
versioning system.
Until now, every baseldap command had two callbacks. The pre-callback
called before data was passed to python-ldap and the post-callback
called after.
This patch introduces class methods, that enable the registration of
new pre/post callbacks. It supports top level functions as well, so
you don't have to touch the original class at all.
It works likes this:
from ipalib.plugins.user import user_show
def test_callback(inst, ldap, dn, attrs_list, *keys, **options):
inst.log.info('hello callback world!')
attrs_list = ['uid'] # only retrieve the user name
return dn
user_show.register_pre_callback(test_callback)
The original callbacks defined in the class are always called first.
Pavel
I think I'd like another registration argument, sort of a hint on where
you'd like this plugin registered: first or last (defaulting to last).
We wouldn't necessarily guarantee where the plugin would get registered
but we could easily handle prepending or appending the new registration.
The argument is already there, but as you said, it doesn't guarantee a
specific order. The "in-class" callback is added when the plugin
instance is created and is inserted at the beginning of the list. More
callbacks could be theoretically added later before this one, but that
probably won't happen.
Not sure how complicated we want this to be but we could also add a
dependency system, so that if some other callback is registered, then
this one comes first (or registration fails), etc.
A priority system might be better and easier to implement in this case.
I'm also thinking of making the callback signature common for all
commands (even though they have different "needs") and adding a context
variable callbacks could use to pass data to each other.
rob
By the way, the approach with class methods and class attributes I'm
using is 100% compatible with the versioning system I proposed before.
You can do this for example:
class user_show(...):
VERSION = (1, 0)
...
user_show.register_pre_callback(some_callback)
user.show_register_pre_callback(some_other_callback)
class user_show(user_show):
VERSION = (1, 1)
...
And the new user_show class will have all the callbacks for the previous
version. Isn't that cool? Man, I love python. It's the hackers holy
grail. :D
Pavel
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
