Libera traduzione di qs articolo:
http://docs.joomla.org/JController_and_its_subclass_usage_overviewvalido per le versioni J >1.6 fino ad ora
Non l'ho riletto, mi serviva capire alcune cose e leggendolo lo scrivevo... tenete presente che chi l'ha scitto non è nemmeno madrelingua, così alcuni concetti li ho un po' aggiustati,... spero di nn aver detto scemenze
.. nn credo cmq, se le notate ditemelo che le correggo, poi magari lo mettiamo tra le guide nel wiki.
-----------------------------------------------------------------------
In Joomla 1.6 ci sono molti miglioramenti riguardanti l'MVC che rendonono più semplice il lavoro dello sviluppatore.
Mentre in Joomla 1.5 esiste un unica classe per il controller che è JController, nella > 1.6 si sono aggiunte, come sottoclassi di JController: JControllerAdmin e JControllerForm. Ognuna di queste tre classi ha un diverso uso nello sviluppo di un componente. Questo pattern è usato per la maggior parte dei componenti del core di Joomla.
Osservando il backend di com_content, si vede che le classi controller si trovano in due posti diversi: una nella root del componente e la seconda all'interno della cartella controllers.
Quello che si trova nella root è il "master controller", il controller principale, che si chiama controller.php e contiene un'estensione della classe principale JController mentre quelli contenuti nella cartella controllers rappresentano i controllers delle entità del componente e contengono classi che estendono le sottoclassi di JController, ovvero JControllerAdmin oppure JcontrollerForm a seconda dell'uso a cui sono destinate.
Il master controller ha il compito di visualizzare la task.
Viene istanziato nell'entry point (Ndr:file con il nome del componente senza com_, che si trova nella root del componente), con la funzione di default se non deve eseguire una task, passandogli come parametro il solo componente e assegnandogli una view di default se non ne viene richiesta una. Se deve eseguire una task prende la variabile dalla request per usare la relativa classe del controller relativo (..pardon).
Se la variabile "task" contiene un dot (.) assume che questa sia nella forma controller.task e quindi controller.relativo_metodo (non si chiamano funzioni anche se sono function!).
In questo caso verrà caricato un controller della cartella controller, che riscriverà la task nel modo usuale controller= task=. Se la sintassi non è in formato "dot"eseguirà quella di default inserita nel master controller (root)
In pratica, se volete usare il master controller dovete specificare o non specificare (verrà usata quella di default) una view; per usare un subcontroller dovete usare la forma "dot" per specificare la task.
Siamo in grado di avere due tipologie di visualizzazione: una che presenta un elenco di record o visualizza un elenco, l'altra mostra un record specifico definito dall'utente (ad esempio il form di modifica di un record).
Se osserviamo ancora com_content nella vista articoli che visualizza elenco di record per l'utente, possiamo notare la task aggiunta ai pulsanti della barra degli strumenti eseguibili in base ai diritti degli utenti. Ad esempio per "Modifica articolo" la task è article.edit.
Per questa richiesta verrà caricato il subcontroller articolo e verrà eseguito il suo metodo di modifica (form di modifica).
Con Joomla >1.6 è sufficiente specificare l'id del record da editare perchè l'utente si trovi in sessione di modifica e venga reindirizzato ad un url di tipo &view=article&layout=edit. La richiesta verrà gestita dal master controller (c'è la view... ricordate?) e verrà presentato all'user la form di modifica.
in questo caso tutte le richieste verranno gestite dal master controller e richiedono una vista.
Se nell'url non è definito il nome di una view verrà usata la view di default usata e verrà eseguita la task di default (display).
Possiamo usarlo per visualizzare un elenco di record, ad esempio: index.php?option=com_content.
Se è definita una view ma non una task, il master controller carica la view specificata ed esegue il metodo display.
Anche questo si può usare per visualizzare una lista di record, ad esempio: index.php?option=com_content&view=articles.
Se sono specificate la view e la task (ma non in formato "dot"), il master controller carica la view specificata ed esegue il metodo specificato dalla task. Questo è il modo per visualizzare il form di edit o presentare all'utente l'item definito. Un esempio è: index.php?option=com_content&view=article&layout=edit.
Quando il master controller crea una view, normalmente carica il model avente lo stesso nome della view e lo mette nella view, poi viene chiamato il metodo display della view. Così facendo, nella view possiamo ottenere i dati dal model usando funzioni come $this->get("Items").
In questo caso la view cercherà un metodo getItems nel model e lo eseguirà.
In questo modo possiamo usare un controller per visualizzare tutti i tipi di informazione con un componente ma sono richieste più view.
Questo riduce le classi controller e ovviamente riduce il codice da produrre per uno sviluppatore.
I subcontroller gestiscono tutte le task CRUD. Gestiscono quindi le operazioni di salvataggio, cancellazione, pubblicazione etc, che non necessitano di vista reindirizzandole alla vista lista. Per modificare o eliminare un record è necessario specificare il suo id e il nome del controller nella forma plurale come articles.delete, articles.publish_up o articles.publish_down. Questo subcontroller è ereditato generalmente da JControllerAdmin che sopprime il metodo display per default.
L'altro tipo di CRUD, come aggiungere o modificare, a prima vista, prepara i dati e presenta all'utente il form. Ma in un componente Joomla! 1.6 non succede questo. Osservando questo tipo di subcontrollers, ContentControllerArticle ad esempio, si vede che eredita sempre da JControllerForm. Ma nessun form viene presentato all'utente in questa richiesta, si limita a memorizzare l'item (id articolo) in una variabile di sessione dell'utente e a fare un redirect al controller principale (master). Siccome la task non è stata specificataviene eseguito il metodo display come task di default
La prima richiesta elaborata dal subcontroller, potrebbe contenere task = article.edit e cid [] = 3; il subcontroller creerà un URL di questo tipo: index.php? option = com_content & view = article & layout = edit, e reindirizza l'utente al controller principale.
