Ciao,
non è che c'è qualche registrazione di un componente fatta via python?
Mi sembra il tipico caso in quanto i vari component.adapts etc NON
vengono visti se il file non viene in qualche modo importato, e quindi
non vanno a finire in quella simpatica global variable che è il register.
In alternativa, la registrazione dell'utility via ZCML è sbagliata:
anche qui potrebbe essere l'uso sbagliato di "component" e "factory".
Per chiarire:
* "factory" è un oggetto callabile che, chiamato () con certi parametri
(nessuno nel caso dell'utility), ritorna un'istanza del componente. Una
definizione di classe e una funzione sono i primi esempi che vengono in
mente.
* "component" è l'istanza di un oggetto: ad esempio se nel tuo python hai:
class MyGreatUtility(object):
"""This utility rocks my socks
"""
my_great_instance = MyGreatUtility()
puoi registrare "my_great_instance" come component. Lo sconsiglio perché
poi dovresti rendertelo threadsafe da solo, e non è mai una grande idea.
Scusami se ho ripetuto cose già stra-conosciute ma sono le uniche cose
che mi vengono in mente a proposito.
No, in realtà ce n'è un'altra: sconsiglio vivamente di fare qualcosa del
genere:
class MyWhateverClass(...):
the_utility = getUtility(IMyUtility, u"my_utility")
perchè questo sposta la risoluzione (e.g. i lookup nel component
registry) nella fase di "import"[1] dei vari componenti, e l'ammontare
di race condition in tale momento è un casino da tenere traccia.
Quindi la getUtility va dentro l'__init__().
[1] Qui la cosa è un pochettino complessa, in quanto in python non
esiste una fase di definizione del codice e una di runtime propriamente
definite. Questo dà grande flessibilità ma anche "enough rope to hang
yourself with", nella migliore tradizione UNIX ;).
On 12/01/2009 11:40 PM, SauZheR wrote:
> Salve a tutti.
> Non riusciamo a splittare decentemente in file py diversi le classi
> necessarie alla collaborazione dei moduli plone.z3cform e
> collective.lead.
>
> Infatti definendo all'interno di un unico file:
> - classe collective.lead.Database che inizializza engine, sessioni, e tabelle
> - classi wrapper delle tabelle relazionali alle quali per comodita'
> facciamo implementare l'interfaccia che descrive il form schema
> - classi interfaccia del form schema
> - classi crud.form
>
> e registrando la named utility del database, le browser:page delle
> form in configure.zcml,
> tutto funziona egregiamente.
>
> Abbiamo provato, per amor di ordine, a definire in un file la classe
> Database e in file diversi le varie classi crud.form, relative
> interfacce e classi wrapper.
> Quello che otteniamo, all'avvio di zope, e' un component lookup
> error al momento della chiamata getUtility(IDatabase, 'mio.db') fatta
> all'interno delle action della crud.form di turno (la prima,
> nell'ordine, ad essere compilata).
>
> La cosa strana e' che se inseriamo un pdb prima della chiamata e
> proviamo a dare manualmente un provideUtility(...) la successiva
> getUtility va a buon fine e l'applicazione gira.
> Non abbiamo cambiato le registrazioni zcml (a meno, ovviamente, dei
> percorsi dei moduli/classi), e nemmeno il loro ordine.
>
> Le uniche differenze, alla fine, sono che classi e interfacce vengono
> importate in cima al file anziche' essere definite nello stesso.
>
> Ora tutto questo per voi ha senso?
>
> Grazie,
> alessandro.
>
>
--
Simone Deponti
_______________________________________________
Plone-IT mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html
