Wedgefish è stato strutturato con un'architettura a moduli che consente di aggiungere nuove funzionalità con facilità e mantenerle separate a livello implementativo, per renderle più facilmente mantenibili e modificabili.
Lo stesso nucleo del sistema è stato suddiviso in entità distinte, ciascuna delle quali è contenuta in una cartella separata.
Il potente gestore di libreria consente di richiamare una qualunque funzione contenuta in un modulo, senza doverlo includere esplicitamente nel sorgente della propria applicazione: è sufficiente abilitarlo nella configurazione globale o in quella del sito.
Un modulo in Wedgefish non è un semplice "francobollo" che è possibile incollare su una posizione della pagina, come avviene con altri programmi di questo tipo.
Benché sia prevista in futuro la realizzazione di templates a blocchi e di un modulo nuke che consentirà di selezionare elementi forniti dai moduli da disporre su posizioni predefinite di un layout compatibile, Wedgefish preferisce lasciare di norma massima libertà al grafico (ove si intende con tale nome colui che crea l'impostazione del sito in HTML, non solamente le immagini) di decidere come strutturare il suo sito, senza costringerlo ad accettare un'impostazione rigida a righe e colonne data da un particolare tema.
Occorre ricordare, per quanto ovvio, che non è possibile prendere direttamente un modulo studiato per un'altra piattaforma e riutilizzarlo in Wedgefish, se non altro per la differente impostazione tecnica: ciò del resto è vero per la maggior parte delle piattaforme. Tuttavia dovrebbe essere possibile con meno difficoltà integrare funzioni e classi sviluppate da terze parti, che si limitino ad accettare parametri e restituire risultati, senza produrre output e senza richiedere la presenza delle API di una determinata piattaforma.
Sebbene lavorare con i moduli faciliti molto l'integrazione ed il riutilizzo di codice tra vari siti, bisogna notare comunque che, in maniera diversa da quanto accade con altri sistemi, non è assolutamente necessario sviluppare un nuovo modulo per implementare ciascuna delle funzionalità che compongono un sito: se lo si desidera, tutto il codice applicativo può inizialmente essere inserito direttamente nei controllers, per poi ricavarne solo in seguito dei moduli. In questo modo lo sviluppo di nuovi prototipi di applicazione è molto velocizzato, ed è inoltre possibile fare aggiunte e modifiche "al volo" senza doversi preoccupare di dover rendere, da subito, tutto quel che si scrive compatibile con altri siti che dovessero far uso dello stesso modulo.
Questa scelta è stata presa al fine di ridurre il più possibile i formalismi ed i vincoli che è necessario seguire durante la creazione di nuovi siti, e consentire di poter toccare subito con mano i risultati, relegando ad un secondo tempo la classificazione e la standardizzazione per l'utilizzo generale di quanto creato.
Struttura dei moduli
Ogni modulo in Wedgefish dovrebbe contenere una o più delle seguenti cartelle:
| Nome | Scopo |
|---|---|
| controllers/ | Controllers di default del modulo (per le pagine di amministrazione e del sito) che possono essere copiati nel layout del sito e quindi personalizzati secondo le esigenze, oppure inclusi a loro volta dai controllers di un template stile "Nuke". |
| cli/ | Funzioni che implementano comandi che verranno resi disponibili abilitando il modulo nella CLI. |
| doc/ | Descrizione del modulo (vedere di seguito), documentazione e manuali. |
| l10n/ | Files .po, uno per ogni lingua, che contengono le traduzioni di tutte le stringhe di testo contenute nel codice e nelle view del modulo. |
| lib/ | Funzioni e classi che svolgono compiti di elaborazione propri del modulo e restituiscono risultati indipendenti dall'output, utilizzate da tutti i front-end (come la CLI, i models e i controllers). |
| models/ | Files XML che definiscono le classi che vengono create dal modulo e gli items che esso può installare nel sito e funzioni che possono essere utilizzate dai controllers per popolare direttamente le view fornendo loro il nome degli elementi e leggendo i dati dal WODBMS. |
| views/ | Views di default del modulo (per le pagine di amministrazione e del sito) che possono essere copiate nel layout del sito e quindi personalizzate secondo le esigenze, oppure incluse dinamicamente da un template stile "Nuke". |
Notare che non è obbligatorio che le funzioni di utilità siano contenute nella cartella "lib", così come i controllers nella cartella "controllers" e le views nella cartella "views". Tuttavia seguire questa classificazione aiuterà nella comprensione del funzionamento del modulo da parte di altri sviluppatori, e consentirà alla piattaforma di identificare in maniera automatica la giusta collocazione delle risorse.
Ogni modulo dovrebbe contenere un file di nome "package.txt" nella cartella "doc", che descrive il modulo e le sue dipendenze. Questo file ha un formato molto simile al file "debian/control" contenuto nei pacchetti Debian: ogni riga inizia con il nome del campo (ad es. "Name:") e prosegue con il suo contenuto.
La differenza è che l'ultimo campo deve essere sempre "Description:" e tutte le righe successive verranno considerate come parte della descrizione (consentendo quindi di andare a capo, senza dover inserire uno spazio a inizio riga).
Installazione dei moduli
I moduli possono essere abilitati a livello globale o del singolo sito.
Abilitare un modulo vuol dire semplicemente rendere disponibili le sue funzioni di libreria per poter essere richiamate da altri moduli o dai controllers, e consentire di inserire le sue funzioni plugin in qualunque punto dell'esecuzione del programma. La semplice abilitazione di un modulo non produce alcun output sul sito di per sé!
È necessario quindi "installare" una o più parti del modulo nel sito per poterne utilizzare appieno tutte le funzionalità(1). Per "installare" si intende copiare le classi e gli oggetti necessari nel WODBMS relativamente al sito corrente: questo è molto simile concettualmente al creare tabelle nel database di un sito e copiare una serie di script PHP nella sua cartella.
Le risorse installate potranno poi essere liberamente personalizzate secondo le esigenze: sarà quindi possibile aggiungere nuovi campi alle classi importate e modificare l'URL, la view e il controller degli oggetti creati. In questo caso, tuttavia, se dovesse essere rilasciata una nuova versione del modulo, i conflitti tra i nuovi oggetti e quelli personalizzati dovranno essere risolti a mano (per minimizzare tale evenienza, i moduli devono essere progettati per concentrare la maggior parte delle loro funzionalità nelle funzioni di libreria e nei models, relegando quindi a view e controllers una funzione prevalentemente di presentazione).
(1) l'installazione dei moduli verrà implementata in una prossima versione della piattaforma; attualmente, quando un modulo li richiede, classi e oggetti devono essere importati a mano dai files XML forniti nella cartella "models"