[Plone-IT] Re: Z3CForm e collective.lead (sqlalchemy) impossibile splittare le classi in piu' file.

Gianni Cozzolongo gianniftp a gmail.com
Mer 9 Dic 2009 11:36:06 UTC


il problema e'  proprio quello.
riportando la getUtility nei metodi la cosa riprende a funzionare
regolarmente.

ma quindi adesso la domanda e' :

e' necessario creare un istanza dell'utility ogni volta che si vuole
accedere al db?


Gianni





2009/12/9 SauZheR <sauzher a gmail.com>

>
>
> Il giorno 09 dicembre 2009 09.55, Simone Deponti <shywolf9982 a gmail.com>ha scritto:
>
> 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")
>>
>
> e' esattamente quello che abbiamo fatto :)
>
> In realta' pensavo fosse opportuno definire l'utility come variabile di
> classe essendo una connessione ad un db, quindi sfruttabile da tutti gli
> oggetti istanziati senza dover aprire nuove sessioni.
>
> Appena in ufficio verifico che il problema sia proprio questo.
>
> Grazie infinite,
> alessandro.
>
>
>
>
>>
>> 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
>> Plone-IT a lists.plone.org
>> http://lists.plone.org/mailman/listinfo/plone-it
>> http://www.nabble.com/Plone---Italy-f21728.html
>>
>
>
>
> --
>  bye
> SauZheR
> ************************************
> l'iterazione è umana...
> la ricorsione, Divina!
> ************************************
> reply to: sauzher AT gmail DOT com
>
> _______________________________________________
> Plone-IT mailing list
> Plone-IT a lists.plone.org
> http://lists.plone.org/mailman/listinfo/plone-it
> http://www.nabble.com/Plone---Italy-f21728.html
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.plone.org/pipermail/plone-plone-it/attachments/20091209/72ca1fb7/attachment.html>


Maggiori informazioni sulla lista Plone-IT