Questo e' quello che dice la docsting del metodo:
Subobjects themselves are represented as individual files or
subdirectories within the parent's directory.
If the import step finds that any objects specified to be created by the
'structure' directory setup already exist, these objects will be deleted
and then recreated by the profile. The existence of a '.preserve' file
within the 'structure' hierarchy allows specification of objects that
should not be deleted. '.preserve' files should contain one preserve
rule per line, with shell-style globbing supported (i.e. 'b*' will match
all objects w/ id starting w/ 'b'.
Uno che capisce da qua?
Poi io mi chiedo: perchemmai un GS (che per definizione e' additivo)
dovrebbe cancellare degli oggetti dallo ZODB (in fase di install) se nessuno
glie lo dice? Tu forse intendi il .delete... ma a questo punto uno dovrebbe
specificare una lista di oggetti da cancellare nel .delete ed una lista di
oggetti da preservare DA questo .delete in .preserve... tantovale non
inserire tali oggetti nel .delete... non so, a me sembra ridondante.
In piu', se io installo il mio prodotto che crea contenuti di default,
questi contenuti vengono aggiornati, le directory riempite di altri
contenuti ecc ecc... poi rilascio una nuova release del mio prodotto... ho
che tutta la contenutistica creata in esercizio va a farsi benedire. Il
fatto che non ci sia un modo per prevenire cio' mi lascia un po' cosi...
Poi ho provato ad indentare quelle due righe e tutto sembra funzionare
correttamente: su un plone vergine i contenuti vengono generati; su un plone
gia' istanziati i contenuti in .preserve vengono preservati.
Sara' che ho pure mal interpretato... ma piu' vado a fondo e meno trovo i
vantaggi nell'utilizzare GS al posto di script imperativi di
install/uninstall.
uncomfortably numb,
alessandro.
Il 14 maggio 2008 18.30, Riccardo Lemmi <[EMAIL PROTECTED]> ha scritto:
> On Wednesday 14 May 2008, SauZheR at gOOgle wrote:
> > Salve a tutti.
> > Vorrei che deste un'occhiata al pezzettino di codice del metodo import_
> > della classe StructureFolderWalkingAdapter del modulo
> > CMFCore/exportimport/content.py
> >...
> > CMFCore ci viene incontro, dandoci la possibilita' di specificare
> all'uopo,
> > all'interno di un file .preserve, tutti quelli ID di oggetti da appunto
> > preservare.
> >
> > Questo, pero', di fatto non accade: i contenuti vengono brutalmente
> > sovrascritti nonostante siano .preservati.
>
> Secondo me hai interpretato male il senso di .preserve: serve per non far
> cancellare i contenuti presenti nello ZODB ma non presenti su file system e
> non per non aggiornare quelli presenti nello ZODB ma che hanno un file di
> import (che quindi vengono riportati allo stato originale durante un
> import).
> --
> Riccardo Lemmi Email: [EMAIL PROTECTED]
> Reflab S.r.l. - Plone Design, Development and Consulting
> Phone: +39 349 4620820 http://www.reflab.it
>
> _______________________________________________
> Plone-IT mailing list
> Plone-IT@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@lists.plone.org
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html
