Questo testo è una libera traduzione di "Walking through Five to Zope 3" che potete trovare all'URL http://plone.org/documentation/tutorial/five-zope3-walkthrough

Autori

Il documento originale è stato scritto  da Jean Francois (Jeff) Roche insieme a Russ Ferriday. Nasce dalla collaborazione cominciata al Plone Multimedia Sprint nel settembre 2005, subito dopo la Plone Conference di Vienna. Jeff stava effettuando il porting del suo famoso prodotto ZphotoSlides, implementando ATPhoto e ATPhotoAlbum per Plone. Russ ha dato una mano, ma Jeff ha fatto il grosso del lavoro, con l'aiuto di Gawel e di altri, ottenendo un gran risultato col pacchetto di ATPhoto. Ora stiamo lavorando insieme nuovamente per inglobare le caratteristiche del prodotto in ATContentTypes (ATCT) utilizzando Five, in attesa del possibile salto a Zope 3. Possiamo offrire una utile prospettiva perché Jeff ha sviluppato una certa esperienza sulle interfacce di Five, mentre Russ era un novizio  all'inizio di questo lavoro comune. Ci auguriamo di poter condividere quel che abbiamo imparato con voi.

Presupposti

• Avere qualche esperienza nello sviluppo di prodotti Plone.

• Conoscere i principi della programmazione orientata agli oggetti.

• Avere una conoscenza di base di UML.

• Essere interessati ed avere una conoscenza di base dell'architettura a componenti di Zope 3.

I nostri obiettivi

Sempre più gente parla dell'architettura a componenti di Zope 3. Attualmente siamo in un momento di transizione in cui la gente deve mescolare concetti di Zope 2 e Zope 3. Non è facile cambiare il vostro modo di pensare andando verso i componenti di Zope 3, poiché questo si porta dietro molti (interessanti, realmente belli ed utili) nuovi concetti. Non c'è molta documentazione sull'uso dell'architettura a componenti di Zope 3 in Zope 2: proveremo a dare il nostro contributo nella speranza di aiutarvi a progredire verso Zope 3. Se quando avrete letto questo documento penserete che Zope 3 offra un modo piacevole di codificare/pensare allora avremo raggiunto il nostro obiettivo.

Il modello che implementeremo

Abbiamo lavorato all'implementazione mediante Five della funzionalità di archiviazione di ATPhoto, che permette di creare un archivio zip partendo da un albero di oggetti. Avevamo completato e testato un modulo di Archiviazione generico. E lo avevamo persino inglobato nel prodotto ATContentTypes. Ma,  mentre documentavamo quel che avevamo fatto, ci siamo resi conto che avevamo mancato un'occasione per scomporre il nostro modello in componenti più utili e riutilizzabili. Così abbiamo ripreso in mano il nostro lavoro ed abbiamo deciso di isolare un meccanismo generico di ricorsione che potesse essere usato per il traversing e la manipolazione di un'ampia varietà di oggetti o di alberi di oggetti. Ciò ha fatto ritardare la nostra attività iniziale, ma pensiamo che, dati il valore educativo e la riusabilità del prodotto finale, ne sia valsa la pena. Questo tutorial descrive quel che abbiamo fatto. Oltre il valore immediato, potreste trovarlo un utile strumento per i vostri progetti. Sarà parte di ATContentTypes in Plone 2.5.

La separazione delle funzioni, la testabilità e la semplicità di manutenzione sono fattori importanti in termini di modellazione del software. Ma volevamo anche che la gente potesse usare il nostro lavoro: ciò implica essere in grado di comprenderne la logica! Così abbiamo realizzato tre classi semplici da definire che implementano il nostro modello:

• un Operator che sa come operare sui nodi di un albero;

• un Filtro che sa come filtrare gli elementi di un albero, in modo da prendere in considerazione solo gli elementi che ci interessano;

• un TreeWalker, in grado di visitare i nodi di un albero, dati un punto di partenza, un'Operator e, se necessario, un Filtro.

Il comportamento del TreeWalker potrebbe non avere mai bisogno di essere cambiato, mentre l'idea dell'Operator e del Filtro è che saranno sostituiti da nuove classi, per realizzare nuove esigenze. Introduciamo ora il concetto di Interfaccia. Le interfacce sono parte del Python. Ma nel “normale” Python non hanno la stessa potenza fornita nella loro implementazione Java, C++, Delfi, etc.. Zope3 e Five hanno cambiato tutto con il pacchetto delle interfacce, che aggiunge il rigore alla loro definizione e al loro uso,  rendendo funzionante il concetto di adattatore. Abbiamo dovuto definire le interfacce per il Filtro e l'Operator, come vedrete successivamente. Sebbene se non ne avessimo bisogno, abbiamo anche definito un'interfaccia per TreeWalker per imporre maggior rigore ora e maggiore flessibilità successivamente.

Nel diagramma UML riportato di seguito, puoi vedere le seguenti interfacce:

• ItreeWalker

• IOperator

• IFilter

Esse definiscono i contratti di interfaccia per le classi che li implementano.

ITreeWalker è implementato in TreeWalker. E questo è lo stesso TreeWalker con cui farete la vostra operazione ricorsiva.

IOperator è fornito soltanto come interfaccia. Ne realizzerete un'implementazione per fare la vostra operazione. Ad esempio, abbiamo indicato l'ArchivingOperator realizzato per l'Archiver per cui abbiamo fatto il TreeWalker. Potete fornire qualsiasi operator vi sia utile in sostituzione di ArchivingOperator. IFilterFolder è un'interfaccia che potete re-implementare a piacere, se volete processare soltanto determinati tipi di oggetto mentre attraversate l'albero. Vi forniamo un'implementazione di default denominata FolderFilter che potrebbe essere tutto ciò di cui avrete bisogno. FolderFilter prende in considerazione tutte le cartelle ed elementi in quelle cartelle. Parleremo in seguito delle operazioni di filtraggio.

L' UML fornisce una descrizione molto generale di quel che abbiamo fatto. La sezione “Usare il Treewalker” ti mostra come usarlo, e successivamente ne approfondiremo l'implementazione.