Dodicesima e tredicesima settimana – dal 3 al 17 dicembre

Traduzioni

Durante queste due settimane siamo stati occupati a tradurre in italiano le guide di Archtypes e Content Types Plone 2.1, entrambe disponibili online nella sezione documentation di http://plone.org. Le traduzioni saranno presto pubblicate online, e l’indirizzo sarà reso noto nel prossimo capitolo.

Undicesima settimana – dal 26 ottobre al 2 dicembre

installazione della libreria eduCommons

ruolo nel nostro progetto

Abbiamo scelto di installare eduCommon per poter apprendere come un altro gruppo di informatici sono stati in grado di implementare in Plone una libreria dedicata alla formazione.

utilizzo della guida

Nonostante avessimo scelto, per un maggior supporto delle librerie, di utilizzare Plone2.5.4 per sviluppare il nostro sistema, siamo stati costretti a passare temporaneamente all’utilizzo di Plone3.0.3 in linux, per essere in grado di eseguire passo passo la guida reperita al sito http://cosl.usu.edu/projects/educommons/documentation/how-to/installation-instructions.
Purtroppo questa guida, nonostante sia ben fatta, si è rivelata assolutamente lacunosa, dà per scontati un sacco di concetti e prende per buono (implicitamente) che sulla distribuizione linux in utilizzo ci siano già le librerie condivise installate.

ricerca di una distribuzione linux

Abbiamo scelto, per comodità, di installare su una macchina virtuale una distribuzione Ubuntu7.10 leggermente elaborata: dopo aver seguito l’installazione standard (per approfittare del wizard per la configurazioni di tutte le periferiche) abbiamo tolto tutte le versioni python già installate (lasciando solamente la 2.4.4) e abbiamo levato completamente gnome. Il sistema operativo attivo, senza servizi aggiuntivi, utilizza solamente 30 MB di memoria ram.
In università, invece, c’è stata fornita una macchina con istallata una gentoo.

reperimento delle librerie dipendenti

In Ubuntu, abbiamo dovuto installare libz, “A Massively Spiffy Yet Delicately Unobtrusive Compression Library” e il pacchetto python2.4-dev, che fornisce gli header per la compilazione.
In gentoo, invece, abbiamo dovuto aggiungere il pacchetto dev-python/lxml.
In seguito, abbiamo scaricato ed installato le librerie trovate sulla guida.
L’installazione di Zope e di Plone è stata eseguita senza nessun problema.

installazione di eduCommons3.0.0 Final

L’installazione è estremamente semplice: le cartelle contenute nel pacchetto eduCommons vanno copiate all’interno della cartella Products; ovviamente, va riavviato il servizio Zope per permettere alle nuove classi di essere compilate e essere istanziabili.
In seguito, per utilizzare eduCommons va eseguita una nuova istanza di Plone-site da Zope, ricordandosi di selezionare eduCommons nella sezione extension profile.
La guida per l’istanziamento è disponibile su http://cosl.usu.edu/projects/educommons/documentation/tutorial/using-the-unified-installer-with-linux/start-the-site.
Da notare che, per poter avere un sito funzionante, abbiamo dovuto cambiare i permessi a 740 (rwxr— in permessi linux) ricorsivamente per le cartelle Products, lib, var e log.

Decima settimana – dal 19 novembre al 25 novembre

Primi prototipi su Plone

Per iniziare a famigliarizzare con la struttura file system stile di Plone abbiamo iniziato a creare dei prototipi rappresentativi per myCampus.

Prototipo 1: Folder

Il primo prototipo è la versione più semplice del corso di laurea: mediante l’oggetto Folder di Plone, abbiamo creato la struttura del generico corso.

Prototipo 2: Schema Manager

Schema Manager è una funzionalità disponibile installando la Product ATSchemaEditorNG 0.4.4, disponibile solo per Plone 2.5.
Essa consente di creare dei nuovi tipi di oggetti sulla base di oggetti già esistenti nel sistema, e di personalizzarne aspetto, comportamento e, soprattuto, di personalizzare i tipi di oggetto che il nuovo tipo sarà disponibile ad inglobare.
In questo modo, abbiamo creato l’oggetto Corso di laurea, che permette di avere al suo interno solamente gli oggetti Professore e Link.
Notare che parte di queste funzionalità sono altresì disponibili nell’interfaccia di gestione di Zope.

Prototipo 3: ArchGenXML

ArchGenXML è una libreria Python in grado generare, dato un diagramma UML appositamente costruito e taggato, un Product, ossia un nuovo tipo di oggetto che Plone (Zope) è in grado di gestire e di rappresentare.

ArgoUML

ArgoUML è risultata la scelta migliore per poter generare diagrammi UML compatibili con ArchGenXML: questo programma, scritto in java (quindi portabile pressoché su tutti i sistemi) genera di default i diagrammi salvandoli in formato .zargo, uno dei formati perfettamente compatibili con ArchGen.

Utilizzo di ArchGenXML

ArchGenXML è praticamente subito pronto per essere eseguito, l’unica cosa che abbiamo preferito fare, è stata di installare in Python le librerie i18ndude e stripogram.
Dopo aver generato il file .zargo, lo si da in pasto ad ArchGen e, se non sono trovati errori, la libreria produce la cartella del nuovo prodotto, già pronto per essere installato.
Ovviamente, il servizio Zope va riavviato per permettere di trovare la nuova libreria; fatto questo sarà sufficiente andare in Configurazione del sito Aggiungi / rimuovi prodotti per installare il nuovo prodotto.
Abbiamo notato che le cardinalità nelle relazioni fra una classe e l’altra non sortiscono alcun effetto nella traduzione dal diagramma alla Product.

Prototipo 4: Python

Abbiamo pianificato che il prototipo 4 sarà costituito dallo sfruttare il più possibile il supporto di ArchGen, al fine di disegnare col maggior dettaglio possibile, l’architettura del sistema. In seguito, dopo aver generato il prodotto, andremo a raffinare le sorgenti python generate per rendere il sistema meglio conforme alle nostre pianificazioni.

approfondimento su ArchGenXml

Questo applicativo serve a trasformare progetti UML in prodotti utilizzabili in Plone.

Prima fase

Aprire il tool UML a vostra scelta (Noi abbiamo utilizzato ArgoUml). Creare un nuovo modello
UML e aggiungere diagrammi di classe. Scegliere il tool per creare le classi e aggiungeere classi al
diagramma (Sempre ArgoUml). Dare un nome al progetto come MyFirstAGXContent e aggiungere
un attributo MyTextField di tipo text. Per esempio: example_1.xmi

Seconda fase (generazione del prodotto)

Salvare/esportare il modello come un file XMI con il nome MyFirstExample.xmi (o in un formato
contenitore di xmi come .zargo o .zuml). Poi dare il comando:
ArchGenXml.py MyFirstAGXExample.xmi.
ArchGenXml iniziera a generare codice. Quando questo sarà completo si sara creata una nuova
cartella MyFirstAGXExample nella cartella di ArchGenXml (Si puo sovrascrivere il nome della
cartella usando l’opzione -o).

Installazione e uso del prodotto generato

Spostare la cartella creata dentro la cartella Products di Plone (plone/data/products).
Aprire plone e loggarsi come amministratore. Scegliere plone setup dalla barra personale e
scegliere Aggiungi/rimuovi Prodotti. Il nuovo prodotto MyFirstAGXContent dovrebbe apparire
nella lista dei prodotti avviabili per l’installazione. Sceglierlo e cliccare installa. Andare alla
cartella personale. Nella lista degli oggetti che si possono aggiungere alla propria cartella potrete trovare il nuovo prodotto. Aggiungere a un’istanza di test per vedere se funziona.

Interfaccia

Di default, quando viene creata una classe nel proprio diagramma di classi, questa rappresenta un tipo di contenuto
Archetypes.
Si puo aggiungere operazioni al proprio modello per generare metodi nelle classi, e attributi per
generare campi nello schema. Alla fine di questo tutorial c’è una veloce lista dei tipi di campi che si possono usare.
Ci sono tre modi base con cui si possono modificare il modo con cui questi tipi sono generati:

• Si possono impostare uno o piu stereotipi nella propria classe, il quale modifica il tipo di
  classe. Uno stereotipo «portal_tool», per esempio, significa che si puo generare un portal
  tool piuttosto che un sempilce content types.
  


• Si possono usare valori taggati nel proprio modello per configurare molti aspetti delle
  proprie classi, i loro attributi e i loro metodi. Una lista di valori taggati riconosciuti per
  classi, campi e metodi si può trovare alla fine del tutorial.
  Quando vengono letti i valori taggati, ArchGenXml generalmente li trattera come stringhe,
  con poche eccezioni dove sono permessi solo valori non stringhe, come richiesto da valori
  taggati. Se non si vuole che i valori siano quotati come stringhe, prefissatelo con python: Per
  esempio, se si vuole impostare il valore taggato di default per python : [high, low] sulla
  linea degli attributi, si potrà dare default=[high, low] nel LinesFields del proprio
  schema.
  


• ArchGenXml comprende le aggregazioni e le composizioni. Se le proprie classi sono
  aggregate ad altre classi, le prime saranno automaticamente generate dentro la cartella con
  queste classi come content type.
  Se si usa composizioni (identificate da un pentagono nel diagramma) anziche aggregazioni, i
  contenuti delle classi sara aggiungibili solo nel contenitore, altrimenti saranno aggiungibili
  globalmente dal tuo portale di default.
  

Variazioni di Content Types

Classi Semplici

Una classe semplice e basata su BaseContent. Questo e di default se nessun altra opzione la soprascrive.

Eredita delle Classi

Il modo più facile per far un content type è introdurre composizioni o aggregazioni nel proprio modello. Le classi genitori faranno da cartella principale e i figli potranno essere creati solo dentro essi. Si può anche fare delle classi genitori solo dandogli come stereotipo «folder». Molti di questi approci risulteranno in un oggetto derivato dal BaseFolder.
Si può anche dare alla classe lo stereotipo «ordered» (possibilmente in aggiunta a «folder»)
inoltre per fare questo eridita da OrderedBaseFolder. Alternativamente, si può impostare il valore
taggato base_class nella classe da OrderedBaseFolder. Questa e generalmente la tecnica che si puo
usare per sovrascrivere la cartella di base di cui si puo aver bisogno.
Come in una famiglia, i valori taggati additional_parents vi permettono di ereditare da molti oggetti parenti.
Altri valori taggati che potrebbero essere utili per generare cartelle sono:

filter_content_types

Impostare questo 0 o 1 per accendere/spegnere filtri di content types. Se i content types non sono filtrati, le classi saranno trattate come cartelle generali per aggiungere contenuti globalmente.

allowed_content_types

Per specificare impostazioni di allocazioni di content types, per esempio per allocare solo immagini e documenti, impostare su: image, document. Notare che se si usa aggregazioni o composizioni per creare ereditarieta questi settaggi manuali non sono necessari.

Tools del Portale

Un tool del portale e un unica istanza che altri oggetti potrebbero trovare via getToolByName e
utilizzarlo. Ci sono molti tools utilizzabili con plone, come portal_action o portal_skin. Per creare un tool per il portale che istanzi un regolare content types, date alla vostra classe lo stereotipo
«portal_tool». Tools possono trattenre attributi e fornire metodi solo come regolari content types.
Tipicamente, questa configurazione trattiene dati e metodi utili per il resto del vostro prodotto da
usare. Tools potrebbero anche avere conflitti -pagina di configurazione nel pannello di controllo di
plone. Vedere la veloce lista alla fine del tutorial per dettagli sui valori taggati che bisogna
impostare per non generare conflitti.

Classi miste astratte

Marcando la vostra classe come astratta nel vostro modello (di solito opzione spuntabile), questa
non sara aggiunta al content types che sono logicamente parte del tuo modello, ma che non sara
appartenti al vostro prodotto. Per istanza potrete creare un STUB per il tipo di immagini standard di
plone se vorrete includere questo in un oggetto aggregato dentro il vostro content type questo e, il
vostro content type o classe mista nelle vostre classi.

Classi eredi/sottoclassi

Eredi e sottoclassi di una classe sono usate per estendere classi esistenti, o cambiare il loro
comportamento. Usando generalizzazioni di freccie nel vostro modello, potrete ereditare i metodi e
schemi altri content types o classi miste nella vostra classe.

Derivazioni Semplici

Tutti i content type in Archetypes sono derivati da una delle classi basi -BaseContent, BaseFolder,
OrderedBaseFolder e cosi via. Se si volesse spegnere cio, per esempio perche la classe base e stata
ereditata da una classe genitore, si puo settare il valore taggato base_class con valore 0.

Derivazioni multiple

Si può ovviamente usare multiple ereditarieta via molteplici generalizzazioni di freccie nel vostro
modello. Inoltre, se si ha bisogno di usare una classe base che non e nel vostro modello, si puo
impostare il valore taggato additional_parents nella vostra classe con una lista di classi parenti.

Ereditarieta da altri prodotti

Se si vuole ereditare dalla classe di un altro prodotto bisogna creare un STUB classe con il valore
taggato ‘import_from’: questo generera una linea di importazione from value import CLASSNAME
nella classe derivata da questa classe.

Interfacce

Le interfacce sono un modo di FORMALLY DOCUMENTING l’interfaccia pubblica per il tuo
codice. Per convenzione, loro sono di solito nel pacchetto interface (vedi BELOW). Usate
l’interfaccia del vostro software UML per creare nuove interfacce.
Le interfacce non hanno molti FLUFF aggiunti che i content types fanno loro non hanno mai corpi
dei metodi. Loro, comunque, hanno documenti di estensione. Una classe si dice realise di un interfaccia quando questa prevede implementazioni per i metodi definite nell’interfaccia. La
realizzazione UML delle freccie (una linea DOTTED con un vuoto ARROWHEAD) assicurera che
i vostri content types saranno linkati alle interfaccie corrette attraverso l’attributo _implements_.

Pacchetti – Mantieni ordinato il tuo codice

Pacchetti sono entrambi un concetto UML e un concetto Python. In python, i pacchetti sono cartelle
sotto il vostro prodotto contenente un set di moduli (file .py). In UML, un pacchetto e un gruppo
logico di classi, raccolto in una grande cartella con classi al suo interno. Per modulare prodotti
complessi, dovreste sempre usare gruppi di pacchetti.

Come controllare i campi del vostro schema

Lo schema dei vostri content types, generato dagli attributi del vostro modello e dai suoi valori
taggati, contiene campi Archetypes. Ogni campo ha un tipo e un widget. La documentazione Archetypes e la veloce lista alla fine di questo tutorial descrivono come i campi sono avviabili e quali parametri prendono come configurazione.

Uso di valori taggati

Se si vuole impostare un valore taggato su un attributo della vostra classe, in generale, questo valore taggato passera attraverso come parametro per la generazione di campi Archetypes. Inoltre, se si vuole impostare il valore taggato enforceVocabulary con il valore 1 su un attributo, dovrete dare enforceVocabulary=1 per questo campo nello schema generato. Similmente, si puo impostare il widget delle proprieta dei campi preimpostando il valore taggato con widget:widget:label impostando l’etichetta del widget, per istanza.

Valori taggati diversi da stringhe

Come prima, durante la lettura dei valori taggati, ArchGenXml li trattera come stringe, con poche
eccezioni dove sono permessi solo valori non stringhe, come richiesto da valori taggati. Se non si
vuole che i valori siano quotati come stringhe, prefissatelo con python: Per esempio, se si vuole
impostare il valore taggato di default per python : [high, low] sulla linea degli attributi, si potrà dare default=[high, low] nel LinesFields del proprio schema.

Indice nel catalog

Per creare un indice in portal_catalog per questo campo aggiungere il valore taggato index con
valore fieldIndex. Un fieldIndex con il nome dei campi accessori (esempio get) verra creato.
Indici multipli possono essere definiti in una tupla, indici per cataloghi speciali possono essere
prefissati con il nome del catalogo seguito da / (per esempio python: (FieldIndex, member_catalog/textIndex)).
Per includere indici nel catalogo metadata (e avere gli attributi pronti da usare nel nucleo degli
oggetti), inserire :brains (stesso come ordina: schema), (esempio FieldIndex: brains)

Riciclare Campi – copiarli da schemi genitori e modificarli

Potreste aver bisogno di un campo description che solitamente e definito da una schema di classe
genitore (BaseContent, BaseFolder) ma appare sotto un tab delle proprieta e non nella vostra form di
base_edit. Per far si che venga mostrato come campo bisogna solo cambiare una proprieta di questo
campo: schemata = default.
Soluzione: Copiare la definizione del campo. nell’UML aggiungere un attributo alla vostra classe,
dare a questo il tipo copy e un valore taggato schemata con valore default. Impostare valori su i campi copiati e sui loro widget con alcuni dettagli differenti da i nuovi campi definiti, facendo attenzione a questo.

approfondimento su ArgoUML

Introduzione

ArgoUml e un potente e facile software di sviluppo grafico che supporta il design, lo sviluppo e la
documentazione di applicazioni software orientata agli oggetti.
Le sue caratteristiche sono:

• Supporta XMI, SVG e PGML
  


• 100% Piattaforma indipendente grazie all’uso esclusivo di Java
  


• Open Source
  


• Caratteristiche cognitive come: riflettivita, design opportunistico, comprensione e
  risoluzione dei problemi

  
  

Requisiti di sistema

• Qualsiasi Sistema Operativo che supporta Java
  


• 10 Mb di spazio disponibile
  


• Mouse e Tastiera
  


• Java 2 JRE o JDK versione 1.4 o superiore
  

Opzioni di Installazione

Esistono due opzioni di installazione:

Java Web Start

Questa alternativa e ottima per utenti occasionali e test. E’ il modo piu semplice e veloce per
iniziare a usare ArgoUml. É richiesta la connessione alla homepage di ArgoUml
([HTML] 0011FF http://www.argouml.org/):

1. Assicurarsi di avere java web start (http://java.sun.com/products/javawebstart/)
   installato.
   


2. Successivamente lanciare l’Argouml link dalla homepage di ArgoUml.
   


3. ArgoUml sarà scaricato, caricato temporaneamente e inizializzato.
   


4. Successivamente, ArgoUml e avviabile solo con la Java Web Start Console (senza
   che sia necessariamente collegato alla rete internet) e (se connesso), in modo
   completamente automatico, verra scaricata, ogni volta, l’ultima versione disponibile.
   

Distribuzione binaria

Questa versione è ottima per utenti regolari e garantisce che la versione di argoUml non cambi durante il corso del vostro progetto. L’utente dovrà:

1. Assicurarsi di avere Java 2 JRE installato.
   


2. Scaricare l’ArgoUml distribuzione binaria dalla homepage di ArgUml
   Potrebbe, anche, includere il fatto di dover copiare questa versione su di un floppy
   disk o cd a seconda se il computer abbia o meno una connessione ad internet.
   


3. Creare una directory di installazione per ArgoUml.
   


4. Estrarre i file di ArgoUml dentro questa directory
   


5. Far partire il software facendo il doppio click su argouml.jar, o eseguendo il seguente
   comando : java -jar argouml.jar sulla linea di comando, o via batch file
   

Installare Moduli Ausiliari

L’installazione standard di ArgoUml non supporta codici di programmazione come C++, php e C#.
Per far si che questo sia possibile bisogna scaricare, sempre dal sito di ArgoUml, i moduli ausiliari.
Bisogna, poi, scompattare i file scaricati, nella stessa directory di ArgoUml.
Il risultato dovrebbe essere che, la directory che contiene il file argouml.jar, ora contenga anche una sottodirectory chiamata ext, nella quale si trovano dei file .jar per i linguaggi extra.

Opzioni della Linea di Comando

Quando si fa partire ArgoUml dalla linea di comando, vi sono diverse possibilita extra. Per esempio:
java -jar argouml.jar -help; apparirà la seguente schermata:

Usage : [option] [project-file]


Opzioni incluse :


-help mostra queste informazioni


-big usa caratteri grandi


-huge usa caratteri enormi


-nosplash non mostrare il logo all’inizio


-noedem non riportare le statistiche d’uso


-nopreload non caricare prima le classi comuni


-norecentfile non caricare l’ultimo file salvato


-command <arg> comando to perform all’inizio


-batch non far partire GUI


-locale <arg> impostare il linguaggio (e.g. ‘en_GB’)


-open <arg> apri questo file all’inizio


-print <arg> stampa questo file all’inizio (e esci)

É possibile anche impostare i settaggi java che influenzi il comportamento di ArgoUml:
-Xms250M -Xmx500M (Far si che ArgoUml riservi molta memoria per grandi progetti).

Creare dei file .zargo cliccabili (in Windows)

Questo lavoro è solo per chi ha installato la distribuzione binaria.

Per prima cosa, trovato il file zargo, clicca con il tasto destro su di esso. Dovrebbe apparire il
classico menu di windows, includendo anche apri e apri con. A questo punto, bisogna dare una
descrizione per il file come ArgoUml Model, e dire a windows di usare notepad per aprire il file.
Questa operazione serve a dare a windows la possibilita di accettare l’estensione .zargo come file
valido.
Ora, aprire Windows Explorer e dal menu di selezione View -> Options (o su windows XP: tools ->
Folder -> Options…) dovrete dare due (o più). Cliccare il File Types e scorrere la lista la lista di descrizione da dare, ad esempio ArgoUml Model. Cliccare per selezionare questo tipo di file, e
poi cliccare sul pulsante di edit.
Ora, cliccare su Open e poi su Edit. Comparirà una form di dialogo che ha una linea per
l’inserimento del file applicativo da aprire. Ricopiare questa linea:

c:/programmi/Java/j2re1.2.0.01/bin/javaw.exe -jar c:/argoUml/argouml.jar

Sostituire il percorso con quello dei vostri jawaw.exe e argouml.jar se questi sono situati in una
diversa locazione. Cliccare tre volte ok in altrettante finestre di dialogo.

Principi di ArgoUml

Quando ArgoUml parte, mostra un diagrammi di classe vuoto su cui si puo aggiungere varo oggetti.
ArgoUml lavora rispettando i seguenti principi:

Progetto, modello e diagramma

Le operazione salvataggio e apertura dei file avviene su un progetto alla volta. Un progetto
corrisponde a un modello piu informazioni sul diagramma, per esempio, tutto che puoi
editare con la finestra di ArgoUml.
Il modello puo contenere molti oggetti (ModelElements) che formano la descrizione
completa UML del sistema che state descrivendo. Tutti i ModelElements dovrebbero essere
presenti sul diagramma, ma questo non e obbligatorio. Inoltre, il modello che e salvato in
ArgoUml, e indipendente dal contenuto del diagramma.
Questo potrebbe essere spiegato dalla possibilita di generare codice di programmazione dal
modello (non c’è bisogno di altri diagrammi per questo).
Un progetto contiene anche tutte le informazioni sui diagrammi, per esempio, le shapes
(presentazioni) usate per rappresentare vari ModelElements, le loro posizioni, colore, ed altri ancora.
Alcuni ModelElements appaiono in diagrammi multipli, alcuni in uno o in nessuno.
Inoltre, salvando e aprendo progetti si hanno tutte queste informazioni. Per salvare solo il
modello esiste un solo modo ovvero attraverso il menu Tools -> Export as XMI.
Potrebbe essere usato quando viene generato del codice da tool esterni che supportano XMI.

Oggetti

Per selezionare oggetti cliccare con il tasto sinistro del mouse. Le funzionalita di ArgoUml
possono essere attivate dal menu, dalle toolbars, o dai menu di pop-up attivati cliccando con
il tasto destro del mouse sull’oggetto. Molte di queste funzioni lavorano sull’oggetto
selezionato.
Tutti i diagrammi hanno delle toolbar poste in alto che sono usate per aggiungere oggetti al
diagramma stesso.
Molti oggetti possono essere aggiunti e rimossi dal diagramma senza cancellarlo dal
modello. Si puo selezionare un oggetto sul diagramma, e poi, con l’ausilio del menu,
cancellarlo, ma questo restera intatto nel modello come si potra vedere nella struttura ad
albero alla sinistra dell’interfaccia. Anche se rimosso questo potra essere aggiunto al
diagramma stesso o a un qualsiasi altro diagramma cliccando, con il tasto destro, sul nome
dell’oggetto nello schema ad albero e selezionando Add to diagram.

Overview dell’interfaccia

Nella parte alta dell’interfaccia esiste un menu di comandi. Sotto la voce file e possibile
trovare il comando salva (per memorizzare il progetto) e il comando apri (per aprire altri
progetti precedentemente salvati).
Nella parte alta sinistra viene mostrato l’albero modello del diagramma e gli oggetti. Questa
vista puo essere adattata a seconda delle proprie necessita filtrando gli oggetti mostrati e
modificando la struttura dell’albero.
Nella parte bassa destra sono contenuti vari dettagli dell’oggetto selezionato corrente: si puo
selezionare l’oggetto in uno dei livelli superiori e scegliere quali dettagli volere esaminare
usando i tabs.
Nella parte alta destra mostra il diagramma su cui si sta lavorando (uno alla volta). Si puo
tagliare e copiare gli oggetti sul diagramma e si puo usare i veloci link che appaiono quando
si seleziona un oggetto creando dei collegamenti tra i vari oggetti presenti
Nella parte bassa sinistra c’e la lista delle cose da fare (consigli che il software ti da)

Nona settimana – dall’8 novembre al 18 novembre

Primi esperimenti con l’interfaccia di gestione di Zope

Questa fase consiste nell’esplorare l’interfaccia di gestione di zope e provare, in modo casuale, a fare degli esperimenti modificando i contenuti delle principali cartelle.

portal_skin

Tra i contenuti del nostro portale possiamo trovare la cartella portal_skin, la quale contiene tutti i dati riguardanti l’aspetto grafico del portale stesso. Tra le varie sezioni esiste la cartella ‘Custom’ che contiene tutte le nostre personalizzazioni, la cartella ‘archetypes’ che contiene tutti i tipi di contenuto che verranno visualizzati e ovviamente molte altre cartelle.
Il primo esperimento consiste nel ‘personalizzare’ la pagina di edit di un qualunque oggetto. Questa pagina si trova in ‘archetypes’ è si chiama ‘base_edit’; tale pagina viene visualizzata ogni qualvolta si inserisce, dall’interfaccia plone (quindi non da zope), un oggetto (cartella, pagina, favourites, ect…).
Cliccando sulla pagina ‘base_edit’ appare il seguende codice

<tal:block metal:define-macro="master"
define="errors options/state/getErrors | nothing;
Iterator python:modules['Products.Archetypes'].IndexIterator;
schematas here/Schemata;
fieldsets python:[key for key in schematas.keys() if (key != 'metadata') and (schematas[key].editableFields(here, visible_only=True))];
default_fieldset python:(not schematas or schematas.has_key(‘default’)) and ‘default’ or fieldsets[0];
fieldset request/fieldset|options/fieldset|default_fieldset;
fields python:schematas[fieldset].editableFields(here);
dummy python:here.at_isEditable(fields);
portal_type python:here.getPortalTypeName().lower().replace(‘ ‘, ‘_’);
type_name here/getPortalTypeName|here/archetype_name;
base_macros here/edit_macros/macros;
edit_template python:’%s_edit’ % portal_type;
edit_macros python:path(‘here/%s/macros | nothing’ % edit_template);
header_macro edit_macros/header | header_macro | base_macros/header;
typedescription_macro edit_macros/typedescription | typedescription_macro | base_macros/typedescription;
body_macro edit_macros/body | body_macro | base_macros/body;
footer_macro edit_macros/footer | footer_macro | base_macros/footer;
lockable python:hasattr(here, ‘wl_isLocked’);
isLocked python:lockable and here.wl_isLocked();
tabindex tabindex|python:Iterator(pos=7000);
css python:here.getUniqueWidgetAttr(fields, ‘helper_css’);
js python:here.getUniqueWidgetAttr(fields, ‘helper_js’);">

<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en"
lang="en"
xmlns:tal="http://xml.zope.org/namespaces/tal"
xmlns:metal="http://xml.zope.org/namespaces/metal"
xmlns:i18n="http://xml.zope.org/namespaces/i18n"
metal:use-macro="here/main_template/macros/master"
i18n:domain="plone">

<metal:head fill-slot="top_slot">
<tal:block define="macro edit_macros/topslot | nothing"
condition="macro">
<metal:block use-macro="macro" />
</tal:block>
</metal:head>

<metal:javascript_head fill-slot="javascript_head_slot">
<tal:block define="macro here/archetypes_custom_js/macros/javascript_head | nothing"
condition="macro">
<metal:block use-macro="macro" />
</tal:block>
<tal:js condition="js"
repeat="item js">
<script type="text/javascript"
charset="iso-8859-1"
tal:condition="python:exists(‘portal/%s’ % item)"
tal:attributes="src string:$portal_url/$item">
</script>
</tal:js>
<tal:block define="macro edit_macros/javascript_head | nothing"
condition="macro">
<metal:block use-macro="macro" />
</tal:block>
</metal:javascript_head>

<metal:css fill-slot="css_slot">
<tal:css condition="css"
repeat="item css">
<style type="text/css"
media="all"
tal:condition="python:exists(‘portal/%s’ % item)"
tal:content="structure string:<!– @import url($portal_url/$item); –>">
</style>
</tal:css>
<tal:block define="macro edit_macros/css | nothing"
condition="macro">
<metal:block use-macro="macro" />
</tal:block>
</metal:css>

<body>

<metal:fill fill-slot="main">
<metal:main define-macro="main">
<metal:use_header use-macro="header_macro" />
<metal:use_typedescription use-macro="typedescription_macro" />
<metal:use_body use-macro="body_macro" />
<metal:use_footer use-macro="footer_macro" />
</metal:main>
</metal:fill>

</body>

</html>

</tal:block>

Come si può notare è scritto in TAL, richiama molteplici funzioni python e utilizza anche molte macro.
Ora proveremo a modificare queste funzioni e queste macro per capire meglio come funzionano.
Quando abbiamo aperto la pagina, oltre al codice di questa, è presente il pulsante ‘customize’ che serve a personalizzare la pagina; di default viene creata una pagina identica, ma modificabile, nella cartella custom.
Al momento della creazione della nuova pagina viene chiesto il titolo della stessa (io ho inserito : ‘MyEdit’).
Proviamo ora ad aggiungere un oggetto nell’interfaccia plone, si può notare che l’url termina con base_edit. In pratica le funzioni e le macro personalizzano questa pagina base,che è unica, a seconda dell’oggetto trattato.

portal_css

Sezione di Plone che contiene il registro generale degli stili CSS applicati al sito. Oltre ha svolge un ruolo centralizzato di ottimizzazione del codice in fase di pubblicazione, acconsente anche all’effettuazione di caching delle varie versioni di CSS, in modo da permettere ai proxy e alle cache dei browser degli utenti finali di effettuare sempre una resa grafica aggiornata all’ultima versione.

portal_types

Come da descrizione “Controls the available content types in your portal”, permette di controllare tutti i tipi disponibili nel proprio sito: oltre ad elencare i tipi offre la possiblità di rinominare, copiare, cancellare, ed effettuare operazioni di importazione/esportazione dei tipi.