Reading time: 6 – 9 minutes
A vegades quan estem fent un programa ens interessa que el nostre codi pugui ser extés sense haver de tocar la seva estructra, fins hi tot el que ens pot interessar és que aquest codi sigui extés en algunes ocasions i en d’altres no. Un altre requeriment que podem tenir també seria que qui l’extengui no siguem nosaltres. Sovint tot això i molt més s’acostuma a fer amb el que anomenem Plug-ins, per cert, sempre m’ha fet molta gràcia la traducció al català de la paraula: ‘afegitons’.
Doncs bé, com que jo de programació no hi entenc gaire li vaig demanar al Pau que m’ajudés a entendre els models de plug-ins que implementaven alguns programes fets amb Python, ja que m’ineressava integrar aquesta funcionalitat en una serie de codis que estic desenvolupament. En aquest post intentaré explicar com funciona el paradigma dels plug-ins que usa Trac.
Primer de tot cal tenir en compte que Trac usa un patró de desplegament d’objectes anomenat Singleton, o sigui que totes les instàncies d’un objecte es refereixes a la mateixa instància. De fet, no sé dir fins a quin punt és necessari que el codi segueixi aquest patró per usar el sistema de plug-ins; tot i que jo diria que almenys les parts del codi que vulguin ser exteses pel model de plug-ins de Trac l’han de seguir.
Els plug-ins de Trac tenen les següents característiques:
- Un Plug-in és un component que extent la funcionalitat d’un altre component
- Un Plug-in pot extendre un altre Plug-in
Per tal d’incorporar la filosofia que té Trac per suportar Plug-ins al nostre codi cal importar el component ‘trac.core’, d’aquest component usarem el següent:
- trac.core.Interface (classe) s’usa per definir quin és el contracte que hauran de seguir els plug-ins.
- trac.core.ExtensionPoint (funció) quan volem que un component sigui extés usarà aquesta funció per recuperar les implementacions del contracte. Deifineix els punts de hook que té el nostre codi.
- trac.core.implements (funció) quan un component usa aquesta funció és per implementar un contracte, o sigui, que els plug-ins que es construeixin l’han d’usar.
Abans de seguir explicaré que s’enten per contracte. Un contracte és en escència una classe de tipus interficie (python no té aquest model com a tal) que defineix quins mètodes (o altres classes) poden ser extesos dins el component original. O sigui, que cal no només definir quin és el contracte que s’ofereix sinó també documentar-lo el millor possible, explicant quines són les entrades i sortides que s’esperen de cada un dels mètodes/classes.
Perquè tot plegat s’entengui millor el Pau em va posar el següent exemple:
Imaginem que tenim una classe del tipus DNI que implementa una base de dades de DNIs, on té un metode que ens permet entrar DNIs a la base de dades:
class DNI(trac.core.Component):
dni_checks = trac.core.ExtensionPoint(IDNIInput)
def __init__(self):
self._dnis = []
def add(self, dni):
assert not dni in self._dnis, "DNI ja existeix"for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
return
self._dnis.append(dni)
def llista(self):
print self._dnis
Cal fixar-se que la línia:
dni_checks = trac.core.ExtensionPoint(IDNIInput)
el que fa és carregar els plug-ins que extenen la funcionalitat del codi original. A més cal que ens fixem que el paràmetre que usa la funció és la classe que defineix el contracte sobre el que es fan els plug-ins:
class IDNIInput(trac.core.Interface):
def check(dni):
""" Es cridada cada cop que s'entra un nou dni, espera que es retorni un valor boleà"""
Com es pot veure el contracte només defineix un mètode: ‘check’ que ha de tenir un paràmetre d’entrada i espera un valor boleà de sortida.
Cal fixar-se en que la classe DNI cada vegada que afegeixi un element a la base de dades (en aquest cas una simple llista), cridarà a tots els plug-ins que compleixin el contracte per l’ordre en que s’han instanciat (s’han importat al codi original) mitjançant el següent codi.
for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
return
Un exemple de plug-in sobre el codi anterior i que compleix el contracte especificat podria ser aquest:
import trac.core
import dni
class ValidDNI(trac.core.Component):
trac.core.implements(dni.IDNIInput)
def check(self, dni):
if type(dni) is not type("str"):
return False
if len(dni) != 9:
return False
return True
Es pot veure com la classe és una instància de ‘trac.core.Component’ (model Singleton) i implementa la interfice ‘dni.IDNIInput’. A nivell funcional el que es fa és ben simple, comprovem que sigui una cadena de texte i que tingui una mida de 9 caràcters, si això es dona retorna un ‘True’ o sinó un ‘False’.
Un exemple de com quedaria el codi principal seria:
import trac.core
class IDNIInput(trac.core.Interface):
def check(nom):
""" Es cridada cada cop que s'entra un nou dni"""
class DNI(trac.core.Component):
dni_checks = trac.core.ExtensionPoint(IDNIInput)
def __init__(self):
self._dnis = []
def add(self, dni):
assert not dni in self._dnis, "DNI ja existeix"
for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
return
self._dnis.append(dni)
def llista(self):
print self._dnis
Exemples d’ús:
>>> import trac.core
>>> from dni import DNI
>>>
>>> dni_bd = DNI(comp_mgr)
>>> dni_bd.add("38135009C")
>>> dni_bd.add("38135009")
>>> dni_bd.llista()
['38135009C', '38135009']
# importem el plug-in check_dni
>>> import check_dni
>>> dni_bd.add("11111111")
El dni 11111111 sembla no ser correcte
>>> dni_bd.add("11111111A")
>>> dni_bd.llista()
['38135009C', '38135009', '11111111A']
Definim el codi ‘log_dni’ que serà un altre plug-in:
import trac.core
import dni
class LogDNI(trac.core.Component):
trac.core.implements(dni.IDNIInput)
def check(self, dni):
print "Nou dni entrat %s" % (dni)
Seguim amb l’exemple anterior:
# importem ara el plug-in 'log_dni'
>>> import log_dni
>>> dni_bd.add("22222222B")
Nou dni entrat 22222222B
A aquestes altures ja s’han carregat dos plug-ins que treballen un després de l’altre i s’ha pogut apreciar la simplicitat i potència del model. Obviament es poden trobar coses a faltar com per exemple algún element que defineixi el llistat de plug-ins disponibles i que permeti alterar l’ordre en que aquests s’executen però això ja s’hauria de desenvolupar a part.
Espero haver-ho descrit de forma entenedora i sent el més fidel possible a les explicacions del Pau, al que he d’agrair-li l’esforç i dedicació per explicar-me aquest model de Plug-ins de Python.
