Joomla! è un CMS ritenuto troppo spesso una soluzione esclusivamente for dummies : in questo intervento cercheremo di sfatare questa convinzione andando ad analizzare le feature che la versione 1.5 ha “introdotto” a favore degli sviluppatori. Verranno proposte, per ogni capitolo del talk, slide introduttive e di approfondimento, concludendo con un case study per ogni tematica proposta. Obiettivo del talk sarà quello di comprendere quanto Joomla! sia una soluzione che offre grandi vantaggi fondendo abbattimento di costi, elevata relazionabilità con il cliente finale e buona estendibilità per le esigenze dello sviluppatore.

1. Joomla 1.5 per gli sviluppatori
Joomla! 1.5
CMS a mani tese verso gli sviluppatori
A cura di Nadalin Alessandro

2. Overview dell'intervento
Joomla! a grandi linee
obiettivi del talk
architettura MVC
template parameters
layout overrides
analisi pratica del
framework

3. Il passato di Joomla!
La versione 1.0 vedrà terminare il supporto a Luglio.
Spariranno dalla JED le estensioni non native per la
versione 1.5 così come le board di supporto del
forum ufficiale.
I plugin per la migrazione ( ETL ) stanno aumentando
in questi primi mesi del 2009
( http://extensions.joomla.org/extensions/extension-
specific/migrator-extensions ).

4. Il presente di Joomla!
La versione 1.5 è la branch da utilizzare: stabile,
sicura, ottimizzata.
Essa è arrivata alla release di mantenimento 1.5.10,
attualmente l'ultima versione stabile del CMS e
l'unica consigliata per siti di produzione.
Attualmente la branch 1.5 non prevede
implementazioni, ma solo security updates e bug
fixing.
Nuove release vengono rese pubbliche ogni 8
settimane circa.

5. Il futuro di Joomla!
La prossima versione minore del CMS, la 1.6, ha
giunto lo stadio di Alpha ( pubblica via SVN ).
Principali e attese novità saranno l'implementazione
di un ACL/ACS nativo potente, MOOtools 1.2, una
classe JForm e una tassonomia meglio organizzata.
Non si hanno ancora notizie certe sulla data
probabile del rilascio, quel che è certo è che dovremo
aspettare alcuni/parecchi mesi prima di vedere
Joomla! 1.6 stabile.

6. Comprendere la direzione del CMS
Joomla! 1.5 ha dato un forte segnale riguardo le
policies di OSM, ovvero la volontà di sacrificare parte
dell'immediatezza e della semplicità del CMS in
favore di un core più robuste, che abbia potenzialità
maggiori.

7. Rivalutare il CMS
Joomla! è notoriamente visto come un giocattolo
adatto per le persone che non hanno conoscenze sui
linguaggi di programmazione web-based: la versione
1.5 unisce le opportunità verso essi con quelle offerte
ai developers professionisti.
Il nuovo framework ha fatto si che moltissime aziende
si siano specializzate nella realizzazione o di
templates o di estensioni specifiche.
L'introduzione del pattern MVC è stata la vera
rivoluzione per il CMS.

8. Joomla! prima dell'MVC
La versione 1.0 non era altro che un fork/evoluzione
di mambo open source, e si basava quindi sul
framework originario di quel cms.
L'introduzione del pattern nel nuovo framework ha
significato quindi enormi vantaggi in termini di
risparmio temporale nello sviluppo, soprattutto, delle
nuove estensioni.
Utilizzare un'estensione sviluppate da terze parti
significava quindi esporre il proprio sito a mini-
framework a loro stanti ( Es Virtuemart ).

9. Joomla! con l'MVC
L'introduzione del pattern ha significato un aumento
significativo della portabilità del codice per le future
versioni minori ( Es. 1.6 ), cosa non garantita prima
( com'è avvenuto nella migrazione dalla 1.0 ).
L'MVC introduce maggiore stabilità a livello di
sicurezza, nonché maggiore facilità in termini di
debugging e di customizzazione delle estensioni.
I layout overrides si basano proprio sull'MVC.

10. Template parameters
I template di Joomla! si basano su XHTML generato
dal file PHP ( index.php ) degli stessi.
Esiste la possibilità di inserire, per il cliente finale, dei
parametri che lui può gestire per customizzare in un
attimo il layout del sito: un esempio lampante sono i
CSS stagionali.
Tali parametri sono definiti nel file XML relativo al
template e salvati nel file params.ini dello stesso.

11. Template parameters (2)
I parametri dei template vengono definiti nel file
templateDetails.xml come segue:
<param name=quot;templatecolorquot; type=quot;listquot; default=quot;autunnoquot;
label=quot;templatecolorquot; description=quot;choose the Color of the
Templatequot;>
<option value=quot;autunnoquot;>Autunno</option>
<option value=quot;invernoquot;>Inverno</option>
<option value=quot;primaveraquot;>Primavera</option>
<option value=quot;estatequot;>Estate</option>
</param>
e producono un output similare a:

12. Template parameters (3)
I parametri vengono poi invocati tramite la sintassi:
$this->params->get('param_name');
ovvero nel nostro caso:
$this->params->get('templatecolor');
per essere riutilizzati in situazioni quali:
<link rel=quot;stylesheetquot; href=quot;templates/template/css/
<?php echo $this->params->get('templatecolor'); ?>
.cssquot; type=quot;text/cssquot; />

13. Template parameters (4)
Una volta implementato il parametro relativo alla scelta
del CSS, sarà semplicissimo utilizzare CSS diversi, scelti
direttamente dall'utilizzatore finale del sito.

14. Header variabile
Allo stesso modo si possono implementare
simpatiche funzioni come l'utilizzo, ad ogni refresh, di
un header variabile.
Questo viene fatto modificando direttamente il file in:
/templates/template_attivo/index.php
Utiliziammo una funzione quale getHeader() per
recuperare un'immagine da una cartella del template
( /headers/ ).

15. Colonne collassabili
Utilizzando il metodo countModules() possiamo
rendere un container qualsiasi collassabile in
base alla presenza di determinati moduli.
Una porzione di codice che rende una zona
collassabile è tipicamente delineata da questa
sintassi:
if ( $this->countModules('top' ) )
{
?>
<jdoc:include type=”modules” name=”top” />
<?php
}

16. Layout override
L'override è una caratteristica che è stata aggiunta a
partire da Joomla! 1.5.0, grazie all'introduzione del
framework MVC.
Esso agisce unicamente sulle view dei componenti
scritti seguendo il framework.
L'override è alla base di JoomlaFAP.

17. Layout override (2)
Un piccolo esempio di override:

18. Layout override (3)
Essi appartengono al singolo template e sono
costituiti da una cartella che recita il nome
dell'estensione, contenente una cartella con il nome
della view contenente i file di override.
Per esempio:
/templates/miotemplate/html/com_content/article/default.php
che sostituirà il file
/components/com_content/views/article/tmpl/default.php

19. Layout override (4)
L'override non è applicabile a qualsiasi estensione
per Joomla! 1.5: solo quelle che fanno uso in todo del
framework MVC del CMS stesso possono utilizzare
questa feature.
Esso è importante poiché ci consente di considerare
come due entità separate il core del CMS ed la
nostra personalizzazione.

20. Framework
Analizziamo alcuni degli aspetti del framework di
Joomla!.
Non analizzeremo il modello MVC ora ma
semplicemente alcune classi e metodi che ci
facilitano in fase di sviluppo.

21. Framework – JFactory
E' una classe che provvede a dare i riferimenti per
ottenere le informazioni maggiormente
interessanti a livello di sviluppo.
Fa riferimento alle classi Singleton più importanti
del framework.

22. Framework – mail
Si basano sulla libreria PHPmailer.
$mail =& Jfactory::getMailer();
$mail->addRecipient( 'spam@odino.org' );
$mail->setSubject( 'Test' );
$mail->setBody( 'Una nuova mail di SPAM!' );
if ($mail->Send()) {
echo quot;Mail sent successfully.quot;;
} else {
echo quot;An error occurred. Mail was not sent.quot;;
}

23. Framework – l'utente
Per accedere al dettaglio dell'utente occorre ricorrere
alla fattorizzazione:
$user =& JFactory::getUser();
ed è possibile ricorrere anche al dettaglio di utenti
differenti, ovviamente, da colui che sta visionando la
pagina:
$user =& JFactory::getUser('62');
$user =& JFactory::getUser('odino');

24. Framework – l'utente (2)
Le informazioni sull'utente, che comprendono:
id
name
username
password
usertype
gid e molte altre
corrispondono alle stesse variabili dell'oggetto.
Per ottenere, quindi, lo username dell'utente:
$user->username;

25. Framework – variabili di configurazione
Ogni web application ha, di norma, delle variabili di
configurazione immagazzinate in una classe.
L'accesso ad esse viene garantito, in Joomla!,
sempre dalla fattorizzazione:
$config_vars = JFactory::getApplication();
e possono essere richiamate tramite:
$config_vars->getCfg('variabile');

26. Framework – sessione
I metodi più semplici per gestire la sessione:
$session =& Jfactory::getSession();
$session->set('mia_variabile', 'valore');
$session->get('mia_variabile', 'predefined');

27. Framework – gestore delle traduzioni
Quando sviluppiamo includiamo, ovviamente, anche
del codice che deve essere interpretato dall'utente.
Joomla! fornisce un metodo ( _) della classe JText
per tradurre automaticamente in accordo alla lingua
definita dal sito.
Esso si basa sul parsing dei file INI relativi
all'estensione che contiene le parole da tradurre.
echo JText::_('HI_USER');

28. Framework – il buffer per gli headers
E' possibile gestire il buffer per tutti gli headers
attraverso la classe astratta JDocument e la
fattorizzazione:
$head =& JFactory::getDocument();
che crea un istanza di JDocumentHTML ( che eredita
da JDocument ).
Non è possibile, ovviamente, creare istanze simili per
documenti che non siano pagine web.

29. Framework – il buffer per gli headers (2)
Per gestire elementi generici possiamo ricorrere ai
metodi getHeadData() e addCustomTag().
print_r ($page->getHeadData());
ritornerà un array con tutti gli elementi che
costituiscono la sezione <head> della nostra pagina.
$page->addCustomTag(“<!-- commento -->”);
ci permette invece di inserire qualsiasi codice tra gli
header

30. Framework – il buffer per gli headers (3)
I metatag invece possono essere gestiti tramite
getMetaData() e setMetaData().
Agiscono come i metodi precedentemente
menzionati.
$page->setMetaData(“author”, “odino”);
creerà quindi un metatag quale:
<meta name=”author” value=”odino” />
I metatag godono di un buffer a loro stante.

31. Framework – il buffer per gli headers (4)
Per gestire con facilità l'implementazione di
JavaScript possiamo utilizzare due metodi.
addScript() aggiunge un JavaScript sito su un file
esterno:
$page->addScript(“http://www.example.com/greateJS.js”);
mentre addScriptDeclaration() direttamente una
porzione di codice:
$page->addScriptDeclaration(“alert('hello world!')”);

32. Framework – il buffer per gli headers (5)
Per quanto riguarda i CSS il discorso è similare a quanto
detto per JavaScript.
Utilizziamo i due metodi:
$page->addStyleSheet(“http://www.example.com/greatCSS.css”);
$page->addStyleDeclaration(“body { border:1px solid black }”);

33. Framework – il buffer per gli headers (6)
Esistono metodi per gestire anche favicon e link del
documento.
Metatag, JavaScript, CSS godono di 3 buffer
separati, per mantenere in ordine gli headers.

34. Framework – il documento HTML
Si basa su JDocument, classe astratta che estende
JObject.
JDocument identifica un documento.
La classe JDocumentHTML è quella utilizzata
effettivamente nei nostri script.
Un oggetto di tipo JDocumentHTML include i metodi
per settare la favicon del documento e gli headers
descritti precedentemente.

35. Framework – il documento HTML (2)
Possiamo accedere al contenuto del documento
attraverso getBuffer().
Per applicare l'override del buffer, invece, possiamo
usare setBuffer().
Questi metodi non sono altro che l'attuale chiamata
di:
<jdoc:include type=”modules” name=”top” />

36. Framework – ACS/ACL
L'ACL nativo di Joomla! 1.5 non permette di creare
nuovi gruppi di utenti né di assegnare a singoli utenti
determinati permessi, senza ricorrere alla riscrittura
del codice.
Per ottenere un riferimento globale riguordante l'ACL
occorre effettuare due fattorizzazioni, una relativa
all'utente ed una all'ACL:
$user =& Jfactory::getUser();
$acl =& JFactory::getACL();

37. Framework – ACS/ACL (2)
Il metodo authorize() di oggetti JUser ci consente di
effettuare un check sui permessi nell'effettuare
un'operazione da parte dell'utente.
Restituisce true se, ovviamente, l'utente ha quel
determinato permesso.
$user = Jfactory::getUser();
if ( $user->authorize('com_content', 'edit') )
{
…
}

38. Framework – ACS/ACL (3)
Sempre riferito agli stessi oggetti, la variabile guest è
utilizzato, principalmente, per escludere la
visualizzazione e/o l'accesso agli utenti non registrati.
if ( !$user->guest )
{
…
}

39. Framework – ACS/ACL (4)
Per aggiungere regole sull'ACL nativo possiamo
applicare i metodi della classe JAuthorization, che
invochiamo tramite fattorizzazione.
$acl =& JFactory::getACL();
$acl->addACL('com_content','edit','users','administrator');
Mentre per impedire l'accesso a certe tipologie di
utenti registrati possiamo semplicemente ricorrere
alle variabili di Juser:
if ( $user->usertype === 'manager' )
{
…
}

40. Framework – database
Joomla! 1.5 supporta solo MySQL.
Viene supportata anche l'estensione MySQLi.
Per lanciare una query di scrittura o lettura sul
database ricorriamo a:
$db =& Jfactory::getDBO();
$query = 'codice SQL valido';
$db->setQuery($query);

41. Framework – database (2)
I metodi maggiormente usati:
$result = $db->loadResult();
$result = $db->loadRow();
$result = $db->loadAssoc();
$result = $db->loadObject();
$result = $db->loadResultArray();
$result = $db->loadRowList();
$result = $db->loadAssocList();

42. Framework – URI
Informazioni di base sulle URI
$uri =& Jfactory::getURI();
JURI::base → /
JURI::root → http://www.mysite.tld/
JURI::current → http://www.mysite.tld/index.php?option=com_photo
$URI = JURI::current();
$uri =& JURI::getInstance($URI);
$action = $uri->getVar('option', 'com_frontpage');
$add_uri = $uri->setVar('task', 'view');

43. Framework – parser XML
Joomla! può invocare diversi tipi di parser XML,
tramite:
$xml =& Jfactory::getXMLParser();
Tra le opzioni
dom → domit & domit lite
simple → JSimpleXML
rss/atom → SimplePie

44. Framework – parser XML (2)
JSimpleXML è un parser che estende SimpleXML
$xml =& JFactory::getXMLParser( 'simple' );
$xml->loadFile( 'templates/template/templateDetails.xml' );
$positions =& $xml->document->getElementByPath( 'positions' );
foreach ($positions->children() as $position)
{
echo $position->data() . quot;nquot;;
}

45. Framework – un nostro modulo
Le estensioni si dividono in componenti, moduli e plugin.
Componenti → sono il corpo del sito, associabili ad
articoli, fotogallery e a tutto ciò su cui è primariamente
focalizzata la pagina.
Moduli → sono frammenti di codice visibili e pubblicati
sulle pagine, associabili a widget e piccole apps che
fungono in simbiosi coi componenti.
Plugin → sono frammenti di codice generalmente non
visibili e utilizzati in determinati contesti/azioni.

46. Framework – un nostro modulo (2)

47. Framework – un nostro modulo (3)
Scopo del modulo:
settare gli headers
riconoscere l'utente
agire in base ai suoi permessi
redirezionarlo in base ai risultati di una query

48. Framework – un nostro modulo (4)
Creiamo la cartella mod_phpday
Creiamo, suo interno, la cartella tmp e i file:
mod_phpday.xml
mod_phpday.php
helper.php

49. Framework – un nostro modulo (5)
mod_phpday.xml
<?xml version=quot;1.0quot; encoding=quot;utf-8quot;?>
<install type=quot;modulequot; version=quot;1.5quot;>
<name>phpday</name>
<author>Odino</author>
<version>1.0</version>
<description>Modulo for dummies</description>
<languages>
<language tag=quot;it-ITquot;>it-IT.mod_phpday.ini</language>
</languages>
<files>
<filename module=quot;mod_phpdayquot;>mod_phpday.php</filename>
<filename>helper.php</filename>
<filename>tmpl/default.php</filename>
<filename>tmpl/default.css</filename>
</files>
<params>
<param name=quot;greetingquot; type=quot;radioquot; default=quot;0quot; >
<option value=quot;0quot;>No</option>
<option value=quot;1quot;>Yes</option>
</param>
</params>
</install>

50. Framework – un nostro modulo (6)
mod_phpday.php
<?php
defined( '_JEXEC' ) or die( 'Restricted access' );
require_once( dirname(__FILE__).DS.'helper.php' );
$phpday = modphpdayHelper::getphpday( $params );
require( JModuleHelper::getLayoutPath( 'mod_phpday' ) );

51. Framework – un nostro modulo (7)
helper.php
<?php
class modphpdayHelper
{
function getphpday( $params )
{
return 'phpday';
}
}
?>

52. Framework – un nostro modulo (8)
it-IT.mod_phpday.ini
HI = Ciao
MUST_LOGIN = You must be logged in in order to have full
access to this module
ACCESS_PRESENCE = Eri al PHPday?
SEE_TALK = Guarda i talk che hai tenuto

53. Framework – un nostro modulo (9)
tmpl/default.php
<?php
defined( '_JEXEC' ) or die( 'Restricted access' );
$header =& JFactory::getDocument();
$header->addStyleSheet(JURI::root().quot;mod_phpdayquot;.DS.quot;tmplquot;.DS.quot;default.cssquot;);
$user =& JFactory::getUser();
if ( $user->guest )
{
echo JText::_('MUST_LOGIN');
}
else
{
if ( $params->get( 'greeting' ) == 1 )
{
echo quot;<h1>quot;.JText::_('HI').$user->name.quot;</h1>quot;;
}
echo quot;<p>quot;.JText::_('ACCESS_PRESENCE').quot;</p>quot;;
$db =& JFactory::getDBO();
$query = quot;SELECT presence, talk FROM #__phpday WHERE id = 'quot;.$user->id.quot;'quot;;
$db->setQuery($query);
$result = $db->loadAssoc();
if ( $result[presence] == 1 )
{
echo quot;<p>quot;.JText::_('YES').quot;</p>quot;;
if ( $result[talk] == 1 )
{
echo quot;<p><a href='quot;;
echo JURI::root().quot;index.php?option=com_phpday_vids&source=talks&relator=quot;.$user->id.quot;'>quot;;
echo JText::_('SEE_TALK');
echo quot;</a></p>quot;;
}
}
elseif ( $result[presence] == 1 )
{
echo quot;<p>quot;.JText::_('NO').quot;</p>quot;;
}
}

54. Framework – un nostro modulo (10)
Ecco il nostro modulo come appare, dopo averlo
installato, in backend:

55. Framework – un nostro modulo (11)
Ecco come appare appena ci colleghiamo al sito:

56. Framework – un nostro modulo (12)
Ecco come compare non appena ci autentichiamo:

57. Termine della presentazione
Domande?