You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to extend the Entry class so that I can have situation-specific versions of the class, adding additional class member variables and functions for woking with my organization's business logic. After spending a day working with this, it seems that it might be more difficult to accomplish than the worth of the desired benefit.
Firstly, Entry's are read-only, as told by __setattr__'s output. This got me to move onto the second idea of trying WritableEntry. However, WriteableEntry gets unhappy with adding new class attributes because itwants class attributes, with a few internally important exceptions, to follow the LDAP scheme for the Entry's objectClass. So if you try to use a class attribute that's not in the scheme attribute, __setattr__ complains that you "cannot add" attributes.
class User(Entry):
def __init__(self, dn, cursor):
super().__init__(dn, cursor)
or
class User(WritableEntry):
....
This is where I stopped trying to extend Entry.
I should also mention that I assumed it is required to extend Reader, otherwise there was ostensibly no way to tell Reader to return instances of my subclass of Entry rather than Entry itself. At first I extended Reader and set self.entry_class in the constructor. To my surprise, that did absolutely nothing and I was still getting back Entry's. Eventually, I tried setting reader.entry_class from the function that was calling Reader's constructor (so, after the Reader was fully created) , and only then would the Reader return my Entry subclass.
The only other alternative that I'm currently working with is to fake it: create a class with all my organization's business logic and then have an Ldap3 Entry as a member variable. If an attribute is not found in MyEntry, Python looks for it in Entry. I fear that this would only cause trouble own the road...
class MyEntry(Entry):
def __init__(self, ldap3_entry):
self.entry = ldap3_entry
def __getattr__(self, attr):
if attr not in self.__dict__:
return getattr(self.entry, attr)
return self.__getattr__(attr)
The text was updated successfully, but these errors were encountered:
I am trying to extend the
Entry
class so that I can have situation-specific versions of the class, adding additional class member variables and functions for woking with my organization's business logic. After spending a day working with this, it seems that it might be more difficult to accomplish than the worth of the desired benefit.Firstly,
Entry
's are read-only, as told by__setattr__
's output. This got me to move onto the second idea of tryingWritableEntry
. However,WriteableEntry
gets unhappy with adding new class attributes because itwants class attributes, with a few internally important exceptions, to follow the LDAP scheme for theEntry
'sobjectClass
. So if you try to use a class attribute that's not in the scheme attribute,__setattr__
complains that you "cannot add" attributes.or
This is where I stopped trying to extend
Entry
.I should also mention that I assumed it is required to extend
Reader
, otherwise there was ostensibly no way to tellReader
to return instances of my subclass ofEntry
rather thanEntry
itself. At first I extendedReader
and setself.entry_class
in the constructor. To my surprise, that did absolutely nothing and I was still getting backEntry
's. Eventually, I tried settingreader.entry_class
from the function that was callingReader
's constructor (so, after theReader
was fully created) , and only then would theReader
return myEntry
subclass.The only other alternative that I'm currently working with is to fake it: create a class with all my organization's business logic and then have an Ldap3
Entry
as a member variable. If an attribute is not found inMyEntry
, Python looks for it inEntry
. I fear that this would only cause trouble own the road...The text was updated successfully, but these errors were encountered: