Come già visto per il modulo di amministrazione definiamo il file liveassistant.php che costituisce l’entry point del nostro modulo:

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.controller');
$controller = JController::getInstance('LiveAssistant');
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
$controller->redirect();

Il file definisce il controller che viene definito nel file controller.php presente nella stessa directory:

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.controller');
class LiveAssistantController extends JController {
function messages() {      }
function crea()     {     }
function aggiorna() {     }
function invia() {      }
function aggiornaLista() { }
function cancella() {     }
}

Nel file definiamo la classe LiveAssistantController che estende la classe JController. I metodi definiti sono privi dell’implementazione, ognuno potrà scegliere l’implementazione che più preferisce, sia basata su file system che su base dati. La soluzione prevista salva le chat su file system in formato xml riducendo al minimo l’accesso al db.

A questo punto definiamo le view per la parte pubblica e le agganciamo alle voci del menu. Per fare questo è sufficiente aggiungere un file xml nella directory com_liveassistant\site\views\client\tmpl, che definisce il valore della voce del menù:

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="COM_LIVEASSISTANT_VIEW_DEFAULT_TITLE_CLIENT">
<message>
<![CDATA[COM_LIVEASSISTANT_VIEW_DEFAULT_TITLE_CLIENT]]>
</message>
</layout>
</metadata>

L’utente potrà aggiungere una voce di menù che punti alla view relativa, stabilendone le regole di accesso. Possiamo rendere l’esperienza più piacevole per l’utente realizzando un modulo dedicato.

Come il componente il modulo presenta un file descrittore xml che descrive la struttura del modulo e definisce l’entry point del modulo, nel nostro caso è il file mod_lvieassistant.php

<?

<xml version="1.0" encoding="utf-8"?>
<extension type="module" version="2.5.0" client="site" method="upgrade">
<name>mod_liveassistant</name>
<author>Valerio Finazzo</author>
<creationDate>Marzo 2014</creationDate>
<authorEmail> valerio.finazzo@gmail.com</authorEmail>
<authorUrl>www.valeriofinazzo.it</authorUrl>
<version>1.0.0</version>
<files>
<folder>tmpl</folder>
<folder>assets</folder>
<folder>language</folder>
<filename module="mod_liveassistant">mod_liveassistant.php</filename>
<filename>mod_liveassistant.xml</filename>
<filename>index.html</filename>
</files>
<config>
<fields name="params">
<fieldset name="basic">
<field name="type" type="radio" default="chat" label="tipo modulo">
<option value="client">client</option>
<option value="operatore">operatore</option>
</field>
</fieldset>
</fields>
</config>
</extension>

La sezione config definisce i parametri di configurazione del modulo, nel nostro caso è definito un parametro di tipo radio button che consente di stabilire il tipo di modulo da mostrare. (modulo client o modulo operatore).

Prossimamente rilascerò il package complessivo LiveAssistant, che comprenderà sia il componente che il modulo.

Nel pattern MVC sono presenti le seguenti 3 componenti software:

• model –> responsabile della gestione del dato (offre i metodi di accesso/modifica al dato)
• view    –> responsabile della rappresentazione del dato
• controller  –> gestisce le richieste degli utenti invocando gli oggetti adatti di volta in volta.

Nel nostro caso il compito del componente di back-end sarà quello di gestire i parametri di configurazione del servizio chat, pertanto realizzeremo i seguenti moduli software:

• un componente Model che offre i servizi di lettura e scrittura sulla tabella descritta nel precedente articolo
• un componente View che presenta il dato all’utente
• un componente Controller responsabile di gestire il modello di navigazione e le operazioni richieste dall’utente

Per ogni componente Joomla definisce due entrypoint, uno per la parte pubblica del sito e uno per la parte di amministrazione. Per il componente di amministrazione Joomla definisce entry point un file chiamato componentname.php, disponibile nel path administrator/components/com_componentname/componentname.php.

Nel nostro progetto l’entry point è il file administrator/components/com_liveassistant/liveassistant.php.

All’interno di tale file è presente la regola di definizione del controller

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.controller');
$controller = JController::getInstance('LiveAssistant');
$controller->execute( JRequest::getCmd('task') );
$controller->redirect();

La prima chiamata impedisce l’accesso diretto al file, le chiamate successive definiscono il controller e la regola di redirect in base al parametro task. Joomla cerchà la definizione del controller in un file controller.php presente nella stessa directory dell’entry point. In tale directory viene definita la classe LiveAssistantController che estende JController

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.controller');
class LiveAssistantController extends JController {    }

In assenza di un task specifico il controller invocherà il metodo display, in modo da invocare la view responsabile della visualizzazione del dato. Joomla cerca le view disponibili nel path component/com_[component_name]/views/[name of view]/, nel nostro caso component/com_liveassistant/views/liveassistant/. Le view sono definite in file view.[view_mode].php, dove il view_mode indica il formato della view, nel nostro caso html.

La nostra view contiene il seguente testo

<?php
defined('_JEXEC') or die('Restricted access');
jimport( 'joomla.application.component.view');
class LiveAssistantViewLiveAssistant extends JView
{
function display($tpl = null)
{
$this->addToolBar();
$this->setDocument();
$jinput = JFactory::getApplication()->input;
$task = $jinput->get('task', '', '');
if ($task == 'save') {
$model = $this->getModel();
$model->saveItem($jinput);
}
$this->item = $this->get('Item');
parent::display($tpl);
}
protected function addToolBar()
{
JToolBarHelper::title(JText::_('COM_LIVEASSISTANT_MANAGER'), 
'liveassistant');
}
protected function setDocument()
{
$document = JFactory::getDocument();
$document->setTitle(JText::_('COM_LIVEASSISTANT_ADMINISTRATION'));
}
}

La View è responsabile di costruire la pagina, in particolare essa aggiunge il titolo alla pagina e alla toolbar e gestisce l’aggiornamento dei parametri della chat. Essa invoca il file tmpl/default.php responsabile di mostrare i dati e i pulsanti per aggiornare i dati. Inoltre nella view sono visibili le chiamata al model. Come si può vedere il model non è espressamente indicato, ma è una classe vhe viene inizializzata cercano la classe LiveAssistantModelLiveAssistant che estende la classe JModel. Tale classe fornisce i metodi di lettura e scrittura al db, come si può vedere nell’estratto

<?php
defined('_JEXEC') or die;
jimport('joomla.application.component.model');
class LiveAssistantModelLiveAssistant extends JModel
{
function __construct()
{
parent::__construct();
}
function getItem()
{
if (empty( $this->_data )) {
$query = ' SELECT * FROM #__liveassistant_params ';
$this->_db->setQuery( $query );
$this->_data = $this->_db->loadObject();
}
return $this->_data;
}

Nel prossimo articolo realizzeremo la componente di front-end.

Vediamo prima il modello ERD

Gli attributi della tabella sono:

• id              –> chiave primaria
• enabled     –> indica se la chat è attiva
• frequency   –> indica la frequenza in secondi con cui il client deve verificare l’aggiornamento dei dati
• directory    –> indica la posizione dove verranno salvati le chat
• mail           –>indica la mail dell’operatore cui verranno inviate le notifiche di richiesta help
• title            –>indica il titolo della pagina della chat

Lo script di installazione prevede i seguenti comandi:

DROP TABLE IF EXISTS `#__liveassistant_params`;
CREATE TABLE `#__liveassistant_params` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`enabled` int(1) NOT NULL DEFAULT '0',
`frequency` int(5) NOT NULL DEFAULT '10',
`directory` TEXT NOT NULL ,
`mail` TEXT NOT NULL ,
`title` TEXT NOT NULL ,
PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

INSERT INTO `#__liveassistant_params` 
(`frequency`, `enabled`, `directory`, `mail`, `title`) 
VALUES 
('10', '0', 'directory', 'mail', 'titolo');

In coda alla creazione è previsto l’inserimento in tabella dei valori di default.

Lo script per la disinstallazione prevede semplicemente la rimozione della tabella:

DROP TABLE IF EXISTS `#__liveassistant_params`;

Nel prossimo articolo vedremo come realizzare la compoennte MVC per gestire i parametri della configurazione.

La componente amministrativa consente di configurare le caratteristiche delle chat mentre la componente front-end presenta due funzioni separate:

• per gli utenti guest deve essere possibile l’avvio di una chat
• per gli operatori autorizzati deve essere possibile gestire le chat avviate

<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="2.5.0" method="upgrade">
<name>LiveAssistant</name>
<author>Valerio Finazzo</author>
<creationDate>Marzo 2014</creationDate>
<authorEmail> valerio.finazzo@gmail.com</authorEmail>
<authorUrl>www.valeriofinazzo.it</authorUrl>
<version>1.0.0</version>
<description>Live Assistant</description>
 
<install>
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<files folder="site">
<filename>index.html</filename>
<filename>liveassistant.php</filename>
<filename>controller.php</filename>
<folder>views</folder>
<folder>models</folder>
<folder>language</folder>
<folder>assets</folder>
</files>
 
<administration>
<menu>Live Assistant</menu>
<files folder="admin">
<filename>index.html</filename>
<filename>liveassistant.php</filename>
<filename>controller.php</filename>
<folder>views</folder>
<folder>models</folder>
<folder>sql</folder>
<folder>assets</folder>
</files>
<languages folder="admin">
<language tag="en-GB">language/en-GB/en-GB.com_liveassistant.ini</language>
<language tag="en-GB">language/en-GB/en-GB.com_liveassistant.sys.ini</language>
<language tag="it-IT">language/it-IT/it-IT.com_liveassistant.ini</language>
<language tag="it-IT">language/it-IT/it-IT.com_liveassistant.sys.ini</language>
</languages>
</administration>
 
</extension>

Per prima cosa installiamo il nostro componente dal sito, scaricandolo dal link.

Una volta installato sarà disponibile la voce Chrono Connectivity nel menù Componenti. Selezioniamo tale voce e accediamo alla sezione Management dove saranno disponibili i report creati e le funzioni per la loro gestione.

Creiamo un nuovo report. Il sistema carica un sistema a scheda dove è possibile configurare tutti gli aspetti del nostro report. Sono presenti le schede:

• General
• FrontEnd Settings
• Admin Settings
• Legend
• Auto generated

La scheda General è divisa a sua volta in più sezioni:

• General Settings
• Query Related Settings
• Connection View Settings
• Add/Edit/Delete Links

In General Settings possiamo inserire il nome del report che stiamo creando e la tabella del database a cui vogliamo agganciarlo.

In Query Related Settings inseriamo il codice per la gestione dei filtri da applicare alla nostra query. Il form deve essere popolato in maniera tale che restituisca una query sql che inizi con la clausola WHERE. E’ possibile avvalersi di php ottenendo qualcosa del genere:

<?php
$sql = " WHERE 1 ";
$nome = $_GET['nome'];
if ($nome != null)
  $sql .= " and nome_ricetta like '%" . $nome . "%' " ;
echo $sql;
?>

E’ possibile applicare l’order specificando i campi della tabella separati da ,

In Connection View Settings costruiamo l’aspetto grafico del report. Nella sezione Header definiamo l’intestazione del nostro report in html, è il posto ideale dove aggiungere la sezione filtri. Nella sezione Body definiamo il body del report, questo frammento di codice verrà ripetuto per ogni record della tabella estratto. Con la sintassi {nome_colonna} all’interno della sezione Body possiamo scegliere quale colonna della tabella mostrare. Nella sezione Footer definiamo la chiusura del report, è il posto ideale dove mettere i pulsanti di paginazione.

E’ possibile avvalersi di alcuni tag che chiameranno delle funzioni specifiche del report. I tag supportati sono:

• {pagination} –> attiva i pulsanti della paginazione (disponibile per la sezione header e footer)
• {edit_record} –> attiva il link per la modifica del record (disponibile per la sezione body)
• {delete_record} –> attiva il link per la cancellazione del record  (disponibile per la sezione body)
• {add_record} –> attiva il link per l’inserimento di un nuovo record  (disponibile per la sezione header e footer)

Nella scheda FrontEnd Settings stabiliamo quale form va invocato per la modifica del record e le regole di visualizzazione del report e dei suoi pulsanti di gestione del report.

Nella scheda Admin Settings stabiliamo i campi che devono essere visualizzati sul backend, tramite la funzione ShowData disponibile nella sezione Management.

Questo è tutto. Adesso dovreste essere in grado di creare form, collegarli a tabelle del database ed estrarre i dati in base alle vostre esigenze sia sul frontend che sul backend.

Alla prossima

Si tratta di definire un nuovo form che contenga i campi del form di registrazione di Joomla più i campi fondamentali per il nostro dominio applicativo.In questo form definiamo i campi necessari per Joomla :

• nome
• username
• password
• retype password
• email

Come primo step carichiamo il form manager di Chronoform, selezioniamo il nostro form e accediamo in modalità modifica tramite il Wizard.

Nel wizard selezionamo un componente di tipo FileUpload e con la funzione di drag and drop la aggiungiamo al nostro form. A questo punto configuriamo le properties dell’oggetto e in particolare configuriamo:

• Allowed Extensions
• Maximum File Size in KB

Per fare questo Chronoform ci mette a disposizione una comodo sezione in cui poter definire le caratteristiche della email che vogliamo spedire.

Come primo step carichiamo il form manager di Chronoform, selezioniamo il nostro form e accediamo in modalità modifica.

Il sistema carica il sistema a schede a noi noto e in particolare ci soffermiamo sulle schede General, Setup Email e Emails Template:

• Nella scheda General ci limitiamo ad abilitare la combo Email the results ?
• Nella scheda Setup Email creiamo le email da inviare al submit dell’utente
• Nella scheda Emails Template definiamo il body di ciascuna email definita

• creare una tabella e agganciarla al form creato
• agganciare il form ad una tabella preesistente.

Vediamo il primo caso. Accediamo alla sezione Forms Management, selezioniamo il nostro form e usiamo la funzione disponibile in alto Create Table. Chronoform aprirà un form per la creazione di una tabella con alcuni campi di audit consigliati. In questo form sarà possibile scegliere il nome della tabella e quali campi del form creato mappare sulla tabella.

Creata la tabella torniamo al nostro form e accediamo alla sezione DB Connection. In questa sezione abilitiamo il data storage e scegliamo dall’elenco la tabella appena creta. A questo punto, una volta pubblicato il form, ogni evento di submit si tradurrà in una insert nella nostra tabella.

Vediamo il secondo caso. Stavolta la tabella è già disponibile e quindi non utilizzeremo la procedura di creazione guidata e relativo mapping. Selezioniamo nuovamente il nostro form e accediamo alla sezione DB Connection. In questa sezione abilitiamo il data storage e scegliamo una tabella preesistente con una sua struttura dati precisa. In questo cosa dobbiamo avere l’accortezza che le property del form abbiamo lo stesso nome dei campi della tabella, altrimenti il rischio è quello di generare tanti record vuoti.

Nel momento in cui scrivo sono presenti le versioni:

• 1.5
• 1.6 (versione di transizione, non più supportata)
• 1.7