Norme generali

Il tutorial di Joel Burton, intitolato Best Practices for Plone Development è un punto di partenza essenziale per chi vuole iniziare a sviluppare moduli per Plone. Spiega le nozioni base per scrivere codice sorgente, per gestirlo, per gestire la configurazione, scrivere la documentazione, eseguire operazioni di debug e di test. Alcune parti incominciano ad avere bisogno di un aggiornamento, ma in generale è uno dei migliori modi in cui iniziare a sviluppare.

Gli standard per scrivere codice

• La maggior parte della logica in un prodotto add-on per Plone è scritta in Python. Seguire le buone norme per la programmazione in Python aiuterà a rendere il proprio prodotto comprensibile e facile da mantenere.
• Con la diffusione di zc.buildout, si incoraggia fortemente la distribuzione dei prodotti sotto forma di eggs. Inoltre, le convenzioni nate con Zope 3 scoraggiano l'uso della directory "magica" Products, anche se è incoraggiata la conversione di prodotti basati su Zope 2 in pacchetti usando il namespace Products.*.
• La community di Plone valuta molto gli standard di usabilità e accessibilità, quindi si dovrebbero usare appropriate sintassi XHTML, TALES e CSS. È quindi buona norma controllare che i propri HTML, CSS e RSS siano in linea con gli standard W3C.

• Evitare di usare DTML nel proprio prodotto add-on per Plone. Nonostante Zope contenga il supporto per il linguaggio di scrittura DTML, DTML è stato soppiantato da TAL per creare template e da Python per la logica sottostante.

Pensa alla compatibilità

Plone supporta entrambe le più recenti versioni di Zope (2). Questo è in genere un buon modello che i prodotto dovrebbero ereditare: supportare le due più recenti versioni (principali) di Plone; ad esempio Plone 2.5 e Plone 3.x. Ciò richiederà magari del lavoro aggiuntivo, ma rende il proprio contributo accessibile a molti più utenti.

Come fare a conoscere bene le API

Una delle cose più efficienti di Plone sono le sue API. Tutto ciò che si può fare attraverso l'interfaccia web, lo si può gestire via codice filesystem, manipolando le API di Plone. Ovviamente ciò fa scaturire una domanda: come scoprire quale metodo API richiamare? I seguenti prodotti possono aiutare:

DocFinderTab

DocFinderTab fornisce un'istantaneo accesso online alla API per ogni oggetto della ZMI. È spesso più utile che cercare nel codice sorgente, dato che si possono vedere tutti i metodi delle classi base, ed è anche più utile che guardare nel debugger. Questo prodotto è facilissimo da installare ed usare. non ci sono scuse per non provarlo subito.

Clouseau

Clouseau è un prompt interattivo Zope/Python basato su AJAX che permette di interagire con Zope e Python direttamente dall'interno di Plone. È molto facile da usare, non ha dipendenze ed è molto maneggevole.

I file Install.py di altri prodotti

Un buon modo di capire come muoversi è guardare come sono stati fatti altri prodotti. Si può ad esempio guardare il file Install.py del proprio prodotto preferito. Per esempio, per imparare come installare nuovi tipi di workflow da disco, si può vedere come è stato fatto in PloneHelpCenter.

Per un'ottima introduzione su come usare le API di Plone, consultare:

• ifPeople's Plone API tutorial

Fasi di test e DocTest

Plone ha una solida cultura per quanto riguarda i test in fase di sviluppo. Infatti, molti sviluppatori della community spesso giudicano la qualità di un prodotto dai test effettuati. Dei buoni test possono garantire il buon funzionamento di un prodotto, e aiutano ad evitare che ci siano problemi anche nella fase stessa di sviluppo.

Lo sviluppatore di Plone/Zope 3 Phillip von Weitershausen (PhiliKON) offre i seguenti consigli per quanto riguarda le fasi di test:

• I testi *.txt in primo piano dovrebbero riguardare test di unità se si sta scrivendo un componente di base in stile Zope 3. Se si parla di unit test vuol dire che si dovrebbero usare DocTestSuite/DocFileSuite da zope.testing.doctest, e nessuna delle contorte suite per fasi di test di tipo ZopeTestCase. Se il proprio test ha bisogno di impostazioni, meglio caricare il limite indispensabile. Evitare di caricare ZCML in uno unit test.
• Scrivere un resoconto in cui si coinvolge il lettore, usando la prima persona plurale (il "noi"). Creare il componente, passare in rassegna le sue API, spiegare i casi limiti e perché è necessario stare attenti ad essi (e testarli accuratamente), anche se ciò richiede del tempo.
• Se si stanno scrivendo test funzionali, interagire con l'applicazione usando il browser per i test (Products.Five.testbrowser.Browser, docs in zope.testbrowser/README.txt). È un ottimo modo di testare interfacce utente interattive in un doctest, il risultato sarà di facile comprensione.

Phillip conclude dicendo:

Solo perchè state scrivendo dei doctests non significa che abbiate scritto anche della documentazione. Testare e documentare è difficile e fare queste due operazioni allo stesso tempo può essere un modo di unire le energie, ma significa anche che bisogna concentrarsi molto. Scrivere dei buoni test, e specialmente scrivere dei buoni doctests, può essere molto più impegnativo che programmare. Siate preparati a impiegare molto tempo in queste operazioni, più che nelle vere e proprie fasi di scritura del codice.

Molte altre informazioni utili sulle fasi di test si trovano nel tutorial di Martin Aspeli intitolato "Testing in Plone."

Merita anche una lettura: Agile Documentation with doctest and epydoc

I seguenti prodotti possono aiutare nel generare documentazione per i propri prodotti add-on: