Introduzione alla pubblicazione di oggetti

In Plone si pubblicano oggetti che sono in realtà collocati all'interno di Zope; la maggior parte di essi sono oggetti che sono memorizzati, appunto, nel database degli oggetti. Il concetto è più complicato rispetto all'ambiente Standard Common Gateway Interface (CGI) dove uno script viene eseguito passandogli una serie di variabili relative alla richiesta. Tutto in Plone è un oggetto, tutto in Zope è un oggetto, tutto in Python è un oggetto. Fino ad adesso si è cercato di evitare di utilizzare la parola oggetto utilizzando al suo posto i termini modello di pagina, script e elemento ma tutti questi in realtà sono oggetti, semplicemente oggetti che si comportano in maniera differente.

Quando si richiede un Uniform Resource Locator [4] (URL) a Plone viene invocato un oggetto dell'ambiente. Plone fa questo trasformando l'URL in un path o percorso. Quindi, se l'URL è /Plone/login_form, quello che Plone fa è scomporre questo URL in un path e cercare ognuno di questi oggetti nel database. Plone troverà un oggetto Plone e dentro quello un altro oggetto chiamato login_form. Il percorrere questo percorso è detto attraversamento: essenzialmente Zope risale attraverso questi oggetti e invoca l'ultimo nel path.

Quando Zope chiama l'oggetto login_form, l'oggetto viene eseguito nel suo contesto. Questo termine si incontra spesso in Plone. È banalmente il contesto corrente dell'oggetto che sta per essere eseguito. Nel nostro esempio è /Plone. Il contesto varia molto muovendosi all'interno del sito Plone. Se si fosse richiesto l'URL /Plone/Members/login_form il contesto sarebbe stato /Plone/Members.

Come menzionato il meccanismo di attraversamento è il sistema con cui è possibile accedere agli oggetti in Plone per via programmatica, allo stesso modo che tramite un URL. Questo è simile ad accedere agli elementi di un file system: se si vuole accedere ad una foto nella cartella Miei Documenti in Windows si immette una directory del tipo c:\Documenti e Impostazioni\andrea\Miei Documenti\Fotografia; allo stesso modo per accedere a un oggetto Plone si immetterebbe Members/andrea/Fotografia.jpg. Questo funziona se si ha una serie di cartelle ed oggetti che assomiglia a questo:

Members
  |_ andrea
     |_  Fotografia.jpg

Nell'esempio con il file system si attraversa il disco fisso del computer cartella per cartella. In Plone succede la stessa cosa, solo che Members e andrea sono oggetti.

Una particolarità è che Zope fa distinzione tra maiuscole e minuscole. Mentre in Windows è possibile scrivere Fotografia.jpg o fotografia.JPG, questo non funziona in Plone: è necessario fornire il nome dell'oggetto con le stesse maiuscole e minuscole dell'ID dell'oggetto. Per questa ragione è raccomandato cercare di mantenere tutti gli URL in caratteri minuscoli in modo da ridurre le possibilità di errore da parte degli utenti.

Plone e Zope hanno aggiunto un elemento chiamato acquisizione a tutto questo sistema di pubblicazione. Il concetto alla base dell'acquisizione è quello di contenimento: gli oggetti sono collocati all'interno di altri oggetti chiamati contenitori. Nell'esempio precedente l'oggetto andrea è un contenitore all'interno del contenitore Members all'interno del sito Plone, un contenitore a sua volta (che in definitiva è all'interno del contenitore di applicazioni Zope).

In un ambiente standard orientato agli oggetti, un oggetto eredita il suo comportamento dall'oggetto padre. In Plone e Zope un oggetto eredita il suo comportamento anche dall'oggetto che lo contiene. Un oggetto attraversa la gerarchia di contenimento per determinare i suoi comportamenti.

Quindi, prendiamo l'esempio dell'accesso a Members/andrea/Fotografia.jpg. Cosa avviene se l'oggetto Fotografia.jpg non esiste nella cartella andrea ma esiste più su nella gerarchia? Bene, l'acquisizione lo troverà per noi. Prendiamo la seguente gerarchia:

Members
   |_ andrea
   |_ Fotografia.jpg

In questo caso, se si esegue l'URL, Plone seguirà il path fino a andrea e poi cercherà di trovare Fotografia.jpg, inutilmente dato che non esiste in quella cartella. A questo punto Plone cercherà nella gerarchia di contenimento, che è la cartella Members, dove troverà e restituirà l'oggetto Fotografia.jpg. Il risultato è che l'utente vedrà l'immagine, come al solito.

Tuttavia, se si confronta questo con l'esempio precedente, dove l'immagine era contenuta nella cartella andrea, si trovano alcune differenze fondamentali:

1. il contesto è lo stesso, nonostante l'oggetto si trovi in una diversa cartella. Il contesto è dato dalla posizione dalla quale l'oggetto è chiamato.
2. il contenitore è diverso: il contenitore di Fotografia.jpg è adesso Members, non andrea.

Quindi, quale è la conclusione di tutto questo? Bene, è possibile mettere un oggetto nella cartella principale del sito Plone e tutti gli oggetti potranno accedervi perché sarà individuato per mezzo dell'acquisizione.

Anche se questo probabilmente ha un senso, l'aquisizione può essere abbastanza complicata, specialmente guardando attraverso la gerarchia del contesto (può succedere). Per approfondire il funzionamento dell'acquisizione si consiglia l'eccellente discussione sull'argomento dello sviluppatore di Zope Jim Fulton.

Introduzione alle Template Expressions

Prima di avventurarci nel sistema dei modelli di pagina di Zope è necessario capire TALES. Spesso in un applicazione si ha il bisogno di scrivere espressioni che vengano interpretate dinamicamente. Questi non sono script, piuttosto si tratta di semplici espressioni di una riga (one liners) che possono fare qualcosa di semplice e facile.

Un'espressione è valutata passando ad essa una serie di variabili locali determinate da cosa sta chiamando l'espressione. Il controllo di flusso passa un set di variabili, il sistema dei modelli di pagina Zope Page Template ne forniscono di ulteriori. Per il momento useremo esempi in cui è definito un contesto. Si ricorda che, come detto, il contesto è quello in cui l'oggetto viene eseguito.

Finora abbiamo incontrate alcune espressioni TALES, come ad esempio string:${portal_url}/Software. Tuttavia questo è soltanto un esempio di un'ampia varietà di espressioni. Il principale uso delle espressioni TALES è nei modelli di pagina di Zope, il sistema di generazione dell'HTML di Plone. Nonostante il loro nome possa suggerire che siano adatti solo ai modelli di pagina, molti strumenti in Plone utilizzano questa sintassi per fornire semplici espressioni, come ad esempio le azioni, il controllo di flusso, e la sicurazza. Esistono diverse tipologie di espressioni, le descriveremo una ad una.

context/message
context/cartella/title
context/Members/andrea/Fotografia.jpg

context/cartellaA/title|context/cartellaB/title

not: context/message|nothing

nocall: context/immagine

string: Questa è una stringa piuttosto lunga
string: Questo è il titolo: $title

string: Questo è il titolo di una immagine: ${context/unaImmagine/title}.

string: Il prezzo in $$US è ${context/qualcheCosa/cost}.

python: 1 + 2

python: path('context/Members')

context/Members

python: test(1 - 1, 0, 1)

python: same_type(qualchecosa, '')

Un altro sistema di generazione dell'HTML?

Nei primi anni del Web erano i programmatori i creatori dell'HTML ed essi rapidamente misero assieme dei sistemi per generare automaticamente l'HTML in modo da potersi concentrare sul loro vero lavoro. Con questi strumenti, come ad esempio i moduli CGI del Perl, i programmatori poterono scrivere complicati programmi lato server per la gestione dei contenuti.

Tuttavia, presto ognuno cominciò a scrivere contenuti e questi processi dovevano essere semplificati. Questo ha determinato la nascita di molti linguaggi dove il codice è mischiato all'HTML, delimitato da speciali marcatori. I linguaggi interpretavano il codice contenuto tra i marcatori per produrre il risultato desiderato. Come menzionato, alcuni di questi sono Active Server Pages, JavaServer Pages, e persino interi linguaggi di programmazione basati su questo concetto, come PHP. Zope ha seguito questa tendenza creando il Document Template Markup Language o DTML.

Questi sistemi prendevano l'HTML e sparpagliavano in esso marcatori personalizzati come ad esempio <% ... %> o <dtml-... />. Questo sistema divenne popolare perché è di facile comprensione e gli utenti che già conoscono le basi dell'HTML possono ben padroneggiare l'idea di qualche marcatore aggiuntivo. I grafici possono ignorare il contenuto di questi marcatori e lasciare i programmatori ad occuparsi di essi. I programmatori possono modificare le parti di codice senza modificare i contenuti.

Tuttavia questi sistemi presentano i seguenti problemi:

• I modelli HTML possono diventare difficili da gestire man mano che maggiori contenuti sono aggiunti allo script. Le pagine diventano rapidamente enormi e difficili da gestire.
• La logica ed i contenuti non sono nettamente separati. Essi possono essere separati con alcuni di questi sistemi, tuttavia la possibiltà di sparpagliare pezzi di HTML in ogni pezzo di programma è troppo facile. Spesso contenuti, presentazione e logica diventano un grande ed intricato garbuglio.
• Le pagine non possono essere modificate facilmente. Spesso le pagine o i modelli sono forniti con l'annotazione "non toccare questi pezzi..." perché le modifiche potrebbero compromettere il funzionamento del programma. Gli editor What You See Is What You Get [7] (WYSIWYG) possono essere impostati per non modificare alcuni marcatori ma altri possono essere compromessi. In grandi organizzazioni utenti con diversi ruoli devono modificare la medesima pagina.
• Può essere difficile ottenere un risultato predefinito. Prendiamo, ad esempio, una richiesta ad una base di dati che mostri i risultati in una tabella. Come può un grafico vedere come sarà questa tabella senza eseguire il codice?

Per queste ragioni è stato creato il sistema di modelli di pagina Zope. I page template rappresentano un innovativo approccio; invece che fornire un nuovo sistema di escape coding, il codice viene aggiunto agli attributi dei marcatori esistenti. Non solo il sistema dei Zope Page Templates è libero ed open source, esso non richiede nemmeno Zope. Al momento esistono realizzazioni di questo sistema in Python, Perl e Java.

Introduzione a modelli di pagina e contenuto

Abbiamo imparato che Plone è un sistema di gestione dei contenuti in cui gli utenti aggiungono contenuti al sito Plone attraverso il Web. Gli oggetti che rappresentano i contenuti sono conservati all'interno di Plone e visualizzati al mondo attraverso i modelli di pagina.

Ritornando al precedente esempio dell'accesso a /Members/andrea/Fotografia.jpg discuteremo ora cosa effettivamente succede al contenuto di Plone. Per prima cosa Plone cerca ed esegue l'oggetto Fotografia.jpg; l'oggetto viene eseguito perché non è stato specificato nessun metodo specifico da richiamare. Quando un content type è eseguito un determinato modello viene localizzato ed interpretato. Il contesto per tale modello sarà l'immagine a cui si vuole accedere ed il modello sarà quello associato all'immagine.

Se è stata richiamata sull'immagine una differente azione, ad esempio Members/andrea/Fotografia.jpg/image_edit, l'azione image_edit associata a questo oggetto verrà localizzata e il corrispondente modello verrà restituito. Il Capitolo 11 tratta di come questo avviene in maggiore dettaglio.

In tutti i modelli di pagina, all'interno di Plone, si troveranno riferimenti a here o context. Questo è il contesto del contenuto a cui si sta accedendo. In un modello è possibile quindi riferirsi a context/questo o quello e questo o quello verrà localizzato relativamente al pezzo di contenuto, non al modello. Andiamo quindi a creare il nostro primo modello in Plone.

Creazione del primo modello di pagina

Il metodo standard per creare un modello di pagina è utilizzare la Zope Management Interface (ZMI) [8]. Sfortunatamente la ZMI è scomoda da usare per uno sviluppatore, visto che questo implica modificare il modello tramite una area di testo nel proprio browser Web. L'area di testo fornisce limitate funzionalità rispetto alla maggior parte degli editor; manca di funzionalità quali la numerazione delle righe, l'evidenziazione delle sintassi, e così via. Nel Capitolo 9 si vedrà come utilizzare l'External Editor per modificare i contenuti; questo permette di modificare i contenuti del sito Web in un editor locale come Macromedia Dreamweaver o Emacs. Nel Capitolo 6 si vedrà come far leggere a Plone i modelli di pagina dal disco fisso come file, si potrà quindi utilizzare qualsivoglia strumento per modificarle.

Per creare un modello di pagina, si acceda alla ZMI, si selezioni portal_skins, successivamente si selezioni custom e quindi di si scelga l'opzione Page Template dal menù a tendina come in figura 5-1. Si prema quindi Add e si vedrà la pagina mostrata in figura 5-2.

Figura 5-1. Scelta dell'opzione Page Template

Figura 5-2. Aggiunta un modello di pagina

Si immetta test come ID per il modello di pagina. Si prema dunque il pulsante Add and Edit che porterà alla pagina di amministrazione mostrata in figura 5-3. Si può quindi modificare il modello tramite il Web utilizzando l'area di testo e premere il pulsante Save Changes per memorizzare le modifiche.

Figura 5-3. Modifica del modello di pagina

Alla pressione del pulsante Save Changes il modello di pagina viene interpretato. Se è stato commesso qualche errore nel modello lo si vedrà evidenziato in cima alla pagina. La Figura 5-4 mostra un errore: un marcatore h1 non è stato chiuso. (Come precedentemente menzionato i modelii di pagina devono contenere codice XHTML corretto).

Figura 5-4. Errore nel modello di pagina

Una volta che si è correttamente salvato il modello di pagina, è possibile accedere alla scheda Test per vederlo interpretato. Nella Figura 5-5 si vede come l'intestazione sia stata sostituita dall'ID del modello e come il paragrafo principale adesso includa l'ID del modello di pagina.

Figure 5-5. Generazione della pagina

La finestra di amministrazione di un modello di pagina ha anche le seguenti importanti funzionalità:

Title:

il titolo per il modello, è opzionale. Se si modifica, nel precedente esempio, si nota come nella scheda Test l'HTML risultante sia diverso.

Content-Type:

il tipo di contenuto del modello, solitamente text/html.

Browse HTML source:

restituisce il modello di pagina non interpretato come testo HTML, così come apparirebbe se il modello venisse aperto in un editor HTML.

Test:

mostra il modello di pagina interpretato.

Expand macros when editing:

opzione che fa si che il sistema provi ad espandere le macro. Si raccomanda di mantenere questa opzione non selezionata nella maggior parte dei casi. Le macro sono una funzionalità avanzata e verranno discusse nel Capitolo 6.

Adesso che si è creato un modello di pagina, lo modificheremo un po'. Questo dimostrerà gli argomenti esposti sin qui in questo capitolo. Per esempio se si vuole provare a far eseguire al modello di pagina l'operazione 1+2 aggiungeremo al modello la seguente riga:

<p>1+2 = <em tal:content="python: 1+2" /></p>

Quindi accediamo alla scheda Test per verificare se funziona. Si dovrebbe ottenere quanto segue:

1+2 = 3

Per vedere un esempio di attraversamento del percorso (path traversal), mostriamo il logo del sito Plone. È possibile includere il logo del sito Plone aggiungendo un'espressione di questo tipo al modello di pagina:

<p tal:replace="structure context/logo.jpg" />

Questo crea l'HTML appropriato per includere l'immagine e la mostrerà nella pagina.

Introduzione alle variabili Built-in

Abbiamo visto la sintassi delle espressioni, ora studiamo le variabili che sono passate ad esse quando il modello di pagina viene interpretato. Quanto segue avviene accedendo all'immagine Fotografia.jpg nella cartella Members/andrea, attraverso l'URL /Members/andrea/Fotografia.jpg/.

container

questo è il contenitore in cui il modello di pagina è stato localizzato. Solitamente in Plone si tratta della cartella portal_skins. Si dovrebbe evitare di utilizzare questa variabile perché l'oggetto portal_skins può fare cose inaspettate al significato del contenitore (per esempio potrebbe riferirlo alla cartella andrea).

context

questo è il contesto nel quale il modello viene interpretato. In Plone questo è l'oggetto che è correntemente visualizzato, se si sta visualizzando un oggetto del portale (per esempio un riferimento all'oggetto Fotografia.jpg).

default

qualche espressione ha dei particolari valori predefiniti, documentati separatamente per ogni espressione. Questa variabile è un puntatore a quel particolare valore.

here

equivalente a context.

loop

equivalente a repeat.

modules

questo è il contenitore per i moduli importati. Per esempio modules/strings/atoi è la funzione atoi del modulo Python strings. Include tutti i moduli che è sicuro importare all'interno del sistema dei modelli di pagina di Zope. Per maggiori informazioni vedere il paragrafo Scripting Plone con Python nel Capitolo 6.

nothing

equivalente di None in Python.

options

opzioni passate al modello di pagina, definite solo quando il modello è richiamato da uno script o attraverso un altro metodo, non attraverso il Web.

repeat

l'elemento ripetuto; si veda l'elemento tal:repeat nel paragrafo Introduzione alla sintassi delle espressioni TAL di questo capitolo.

request

richiesta inviata dal client (tutti i valori della richiesta sono visionabili utilizzando lo script test_context sotto riportato). Tutti i parametri passati attraverso i metodi GET o come POST sono ordinati in un dizionario per un facile accesso. Qualche esempio:

request/HTTP_USER_AGENT # il browser usato dall'utente
request/REMOTE_ADDR     # l'indirizzo del computer dell'utente
request/someMessage     # il valore di qualche messaggio, nella
                        # stringa di interrogazione

root:

l'oggetto principale Zope. Per esempio root/Control_Panel restituisce il pannello di controllo di Zope.

template:

il modello correntemente interpretato. Per esempio template/id da l'ID del modello attualmente visualizzato.

traverse_subpath:

contiene una lista degli elementi che devono ancora essere attraversati. Questa è una variabile avanzata e si raccomanda di utilizzarla solo una volta compreso il meccanismo di attraversamento ed acquisizione.

user:

l'oggetto utente corrente. Per esempio user/getUserName da il nome utente dell'utente corrente.

CONTEXTS:

l'elenco di molte di queste variabili.

Il modello di pagina test_context mostra tutti valori di queste variabili oltre che alla posizione di alcuni oggetti (vedere il Listato 5-1). Può essere utile per scovare eventuali errori o comprendere meglio il significato delle variabili. Aggiungiamolo come modello di pagina chiamata test_context quindi accediamo alla scheda Test per vedere il risultato.

Listato 5-1. test_context

<html>
  <head />
  <body>
    <h1>Debug information</h1>
  <h2>CONTEXTS</h2>
  <ul>
    <tal:block
        tal:repeat="item CONTEXTS">
    <li
        tal:condition="python: item != 'request'"
        tal:define="context CONTEXTS;">
            <b tal:content="item" />
            <span tal:replace="python: context[item]" />
    </li>
    </tal:block>
  </ul>
  <h2>REQUEST</h2>
  <p tal:replace="structure request" />
  </body>
</html>

Il modello di pagina test_context produce il risultato mostrato in Figura 5-6.

Figura 5-6. Un esempio di tutte le varibili definite in uno script

Introduzione alla sintassi delle espressioni TAL

Il Template Attribute Language (TAL) fornisce tutti i pezzi necessari alla creazione di una rappresentazione dinamica. TAL definisce otto istruzioni: attributes, condition, content, define, omit-tag, on-error, repeat and replace.

Siccome i modelli di pagina sono documenti XML validi tutti gli attributi TAL devono essere in lettere minuscole e ogni elemento può aver associato ogni istruzione una solo volta. Negli esempi che seguono si sono inseriti dei ritorni a capo all'interno delle definizioni degli elementi per migliorare la leggibilità del codice; questo non compromette la validità del codice ed è abbastanza comune nei sorgenti di Plone. Tuttavia è opzionale e non è richiesto.

<a href="#"
   tal:attributes="href context/absolute_url">
   Qui c'è il Link
</a>

<a href="http://plone.org/Members/andy/book">Qui c'è il Link</a>

<a href="#"
   tal:attributes="href context/absolute_url;
                   title context/title_or_id">Link</a>

<a href="http://plone.org/Members/andy/book" title="Plone Book">Link</a>

<a href="#"
   tal:attributes="href python:request.get('message', default)">
   Link
</a>

<p tal:condition="request/message">
    C'è un messaggio
</p>
<p tal:condition="not: request/message">
    Nessun messaggio
</p>

<i tal:content="context/title_or_id">Qualche titolo</i>

<i>Un determinato titolo</i>

<i tal:content="structure here/title_or_id">Do not escape HTML</i>

<p tal:define="title here/title_or_id">
    ... <i tal:content="title">Titolo</i> ...
</p>

<p tal:define="global title string:Foo bar">
    ... <i tal:content="title">Titolo</i> ...
</p>
<i tal:content="title">Anche qui abbiamo un titolo</i>

<p tal:content="portal_title" />

<p tal:omit-tag="">Questo è un testo</p>

Questo è un testo

<p tal:omit-tag="nothing">Questo è un testo</p>

<p  tal:content="request/message"
    tal:on-error="string: Nessun messaggio">Testo messaggio</p>

<p
  tal:content="request/message"
  tal:condition="request/message|nothing">
    C'è un messaggio
</p>
<p tal:condition="not: request/message|nothing">
    Nessun messaggio
</p>

<table>
  <tr tal:repeat="row context/portal_catalog">
    <td tal:content="row/Title">Titolo</td>
  </tr>
</table>

<table>
  <tr tal:repeat="row context/portal_catalog">
    <td tal:content="repeat/row/number">1</td>
    <td tal:content="row/Title">Titolo</td>
  </tr>
</table>

<ul>
  <li tal:repeat="val context/objectValues">
    First: <i tal:content="repeat/val/first/meta_type" />,
    Last: <i tal:content="repeat/val/last/meta_type" />:
    <b tal:content="val/meta_type" />,
    <b tal:content="val/title_or_id" />
  </li>
</ul>

<p tal:replace="context/title_or_id">Some title</p>

<p
  tal:content="here/title_or_id"
  tal:omit-tag="">Some title</p>

Introduzione all'ordine di esecuzione

L'ordine con cui le istruzioni TAL sono scritte non è l'ordine in cui esse sono interpretate perché esse sono realmente elementi XML (e l'XML non rispetta l'ordine degli attributi). L'ordine in cui le istruzioni sono interpretate è il seguente:

1. define
2. condition
3. repeat
4. content
5. replace
6. attributes
7. omit-tag

Non è possibile utilizzare le istruzioni content e replace sullo stesso elemento perché esse sono mutuamente esclusive. Utilizzando l'istruzione attributes sullo stesso elemento insieme replace o omit-tag non ha significato in quanto gli attributi vengono rimossi. L'attributo on-error non è menzionato nell'elenco perché esso è interpretato non appena si incappa nel primo errore in qualsiasi degli elementi elencati.

Esempio: visualizzare informazioni sull'utente

Per illustrare gli argomenti sin qui trattati procediamo adesso con la creazione di un modello di pagina che esegue un semplice compito: mostrare le informazioni che riguardano un utente del sistema.

In questo esempio un'azienda utilizza internamente Plone come intranet. Ogni dipendente è registrato all'interno di Plone e possiede una login; tuttavia non c'è una semplice pagina che mostri i dipendenti o come contattarli. Creeremo una semplice pagina di informazioni sull'utente che mostri l'indirizzo e-mail, l'home page, una foto, e l'ora dell'ultimo login.

Il primo prototipo di questa pagina è facilmente realizzato con TAL, TALES e un po' di conoscenza delle funzionalità di base degli strumenti Content Management Framework (CMF). Sfortunatamente, visto che le Application Management Interfaces (API) per questi strumenti sono abbastanza complesse, parte del codice risulterà più lungo di quanto non dovrebbe essere. A questo livello non ci si preoccupi troppo dell'API; verrano descritte più approfonditamente nel Capitolo 9. Si dia per il momento l'API per scontata e ci si concentri sul TAL.

Per prima cosa creiamo un modello di pagina; selezioniamo portal_skin, quindi custom*, aggiungiamo un modello di pagina dandogli ``ID`` **user_info modificandolo infine come indicato di seguito. Per il listato completo del modello di pagina consultare l'Appendice A. Esaminando il listato completo si vede che esso comincia con i marcatori html e body.

Per comodità si raggruppano le principali definizioni in un marcatore div:

<div
  tal:omit-tag=""
  tal:define="
    userName request/userName|nothing;
    userObj python: here.portal_membership.getMemberById(userName);
    getPortrait nocall: here/portal_membership/getPersonalPortrait;
    getFolder nocall: here/portal_membership/getHomeFolder
    ">

In questo marcatore div ci sono quattro definizioni: una per ottenere il nome utente ricevuto attraverso la richiesta del client e una per convertire il nome utente in un oggetto di tipo utente. Le ultime due definizioni assicurano di avere dei riferimenti validi ai metodi che restituiscono la foto dell'utente e la sua cartella personale; queste sono nuovamente delle definizioni di convenienza che servono per rendere il codice che segue più semplice. Utilizzare un marcatore div, o qualche altro marcatore simile a questo, che raccolga una serie di definizioni, è una procedura comune all'interno del sistema dei modelli di pagina di Zope. Esso semplicemente mantiene ordine all'interno del codice.

Successivamente inseriamo due semplici condizioni per assicurarci che un utente sia definito:

<p tal:condition="not: userName">
    Non è stato selezionato alcun nominativo.
</p>
<p tal:condition="not: userObj">
    Il nominativo selezionato non esiste.
</p>

Se nessun nome utente è stato specificato nella richiesta, allora l'espressione request/username|nothing assegna alla variabile userName il valore nothing e quindi il test fallisce. In più se il nome utente non è valido la variabile userObj risulterà None e un messaggio di errore verrà visualizzato per entrambe queste condizioni.

Adesso siamo pronti per visualizzare le informazioni sull'utente:

<table tal:condition="userObj">
  <tr>
    <td>
      <img src=""
           tal:replace="structure python: getPortrait(userName)" />
    </td>

Siccome è possibile visualizzare le informazioni relative all'utente solo se un utente è stato trovato, ce ne assicuriamo con una semplice condizione applicata alla tabella: tal:condition="userObj". Per visualizzare una foto dell'utente, utilizziamo il metodo getPortrait precedentemente definito. Questa funzione restituisce l'HTML completo necessario a visualizzare l'immagine: per questo il marcatore structure assicura che esso sia correttamente visualizzato. In aggiunta vogliamo visualizzare alcune proprietà come name ed email. Il codice seguente visualizza una di queste, restituendo la cartella home:

<li
    tal:define="home python: getFolder(userName)"
    tal:condition="home">
    <a href=""
        tal:attributes="href home/absolute_url"
        >Cartella personale</a>
</li>

Per prima cosa si utilizza un define per assegnare l'oggetto che rappresenta la cartella personale dell'utente alla variabile home. In un sito Plone creare una cartella personale per gli utenti è opzionale, quindi è necessario controllare che la cartella esista prima di visualizzare un collegamento ad essa. Fortunatamente, a causa dell'ordine di esecuzione delle istruzioni TAL, la definizione viene interpretata prima della condizione. Con questo si visualizza un collegamento alla cartella utilizzando l'attributo absolute_url dell'oggetto.

Il modello di pagina prosegue con altre righe relative alla visualizzazione di altre utili ed eccitanti proprietà dell'utente. Come la maggior parte delle cose in Plone la chiave risolutiva è trovare le giuste chiamate alle API per poi elaborarne i risultati in base alle necessità.

Infine la pagina termina chiudendo tutti i marcatori che vanno chiusi. Se tutto va bene è possibile consultare la pagina accedendo all'URL http://sitoplone/user_info?userName=[nomeutente] dove [nomeutente] va sostituito con un nome utente che esiste nel sito Plone.

Al momento questo modello di pagina abbastanza limitato. Solo un utente con il ruolo di manager può vedere questa pagina, può visualizzare solo i dati relativi ad un solo utente per volta e le informazioni per l'utente sono piuttosto poche. Nel Capitolo 6 vedremo come espandere questo esempio e come aggiungere la possibilità di riutilizzare qualche componente e la possibilità di tradurre il testo in altre lingue.