Archives

In questi giorni sto mettendo su un piccolo gestionale ed ho deciso di utilizzare le annotation di Zend\Form per creare i crud richiesti per la gestione dei dati inizialmente mi sembrava un ottima soluzione data la semplicità dell’operazione, poi ho scelto di creare questi form direttamente nelle entità essendo appunto strettamente legati, in modo da poter eventualmente cambiare filtri e validatori velocemente in base al tipo di campo creato del database.

Ora mi trovo, soprattutto causa l’integrazione con doctrine a dover costruire dei crud un po’ più complessi per riuscire a gestire bene le Foreign Key, per esempio ho utilizzato ObjectSelect di DoctrineModule per controllare meglio le Select, questo richiede un controllo maggiore che con le Annotation risulta un po’ troppo laborioso.

Qual’è il vero valore aggiunto nel fatto di avere i crud più semplici con le annotation e per un livello poco superiore al basic dei form costruiti con array? A mio parere il gioco non vale la candela, conviene spendere qualche minuto in più ed avere un uniformità maggiore del codice, sempre in prospettiva di dover tornare sul progetto dopo parecchio tempo e dover limitare il tempo perso a cercare un pezzo di form nell’entità e un altro come classe.

Dopo questa breve e poco significativa riflessione torno al lavoro!

è ormai da un po’ di tempo che non scrivo sul blog, dopo un attimo di tour the force mi sono fermato, ho un po’ di lavori da sbrigare ma investo un po’ di tempo in questo articolo, in primis perchè non ho ancora trovato pace, nessun plug in che mi piaccia per l’impaginazione del codice su wp spacciandomi per developer ogni tanto dovrei anche scriverne un po’.. Quindi bando alle ciance degli hydrator ne abbiamo già parlato, ma visto che mi fanno passare notti insonni condivido con voi le mie pene.

Caliamoci nella parte, premessa

• Zend Form Annotation
• DoctrineModule & DoctrineORMModule

Ho creato un Entità doctrine con le annotation per la creazione dell’indispensabile Crud, in sostanza il utilizzare le annotation è un arma a doppio taglio, complicato un po’ l’entità perchè al suo interno sono presenti appunto le annotazione per la creazione del form e poi il numero di form che è possibile configurare è uno. 

<?php
namespace BaseCrud\Entity;
use Doctrine\ORM\Mapping as ORM;
use Zend\Form\Annotation;
use BaseCrud\Entity\Base;
/**
 * @author Gianluca Arbezzano <gianarb92@gmail.com>
 * @ORM\Entity @ORM\Table(name="st_manutenzione")
 * @Annotation\Name("maintenance")
 * @Annotation\Hydrator("Zend\Stdlib\Hydrator\ObjectProperty")
 */
class Maintenance
 extends Base
{
 /**
 * @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue
 * @Annotation\Attributes({"type":"hidden"})
 * @Annotation\Required(false)
 * @var int
 */
 protected $id;

 /**
 * Date of Maintenance
 * @var \DateTime
 * @Annotation\Attributes({"type":"date", "class":"datebox"})
 * @Annotation\Options({"label":"Data Manutenzione: "})
 * @ORM\Column(name="data_man", type="date", nullable=true)
 */
 protected $dataMaintenance;

 /**
 * Tool strickens by drawback
 * @var \BaseCrud\Entity\Tool
 * @Annotation\Exclude()
 * @ORM\ManyToOne(targetEntity="BaseCrud\Entity\Tool", inversedBy="maintenance")
 * @ORM\JoinColumn(name="id_strum", referencedColumnName="id", onDelete="CASCADE")
 */
 protected $tool;

 /**
 * Status Drawback
 * @ORM\Column(type="string", length=5, name="a_man", nullable=true)
 * @Annotation\Attributes({"type":"Checkbox"})
 * @Annotation\Required(false)
 * @Annotation\Options({"label":"Stato: "})
 * @var string
 */
 protected $status;

 /**
 * Deprecated!
 * @ORM\Column(type="string", name="eseguito", nullable=true)
 * @Annotation\Validator({"name":"StringLength", "options":{"min":0, "max":50}})
 * @Annotation\Attributes({"type":"textarea"})
 * @Annotation\Options({"label":"Eseguita: "})
 * @var string
 */
 protected $detected;

 /**
 * @var BaseCrud\Entity\User
 * @Annotation\Exclude()
 * @ORM\ManyToOne(targetEntity="BaseCrud\Entity\User", inversedBy="maintenance")
 */
 protected $user;

 /**
 * Note of Maintenance
 * @Annotation\Validator({"name":"StringLength", "options":{"min":0, "max":250}})
 * @Annotation\Attributes({"type":"textarea"})
 * @Annotation\Options({"label":"Note Prestito: "})
 * @Annotation\Required(false)
 * @ORM\Column(type="string", name="nota_man", nullable=true)
 * @var string
 */
 protected $maintenanceNote;

 /**
 * Get id
 *
 * @return integer
 */
 public function getId()
 {
 return $this->id;
 }

 public function setId($i)
 {
 $this->id=$i;
 return $this;
 }

 /**
 * Set dataMantenance
 *
 * @param \DateTime $dataMantenance
 * @return Maintenance
 */
 public function setDataMaintenance($dataMaintenance)
 {
 $this->dataMaintenance = $dataMaintenance;
 return $this;
 }

 /**
 * Get dataMantenance
 *
 * @return \DateTime
 */
 public function getDataMaintenance()
 {
 return $this->dataMaintenance;
 }

 /**
 * Set status
 *
 * @param string $status
 * @return Maintenance
 */
 public function setStatus($status)
 {
 $this->status = $status;
 return $this;
 }

 /**
 * Get status
 *
 * @return string
 */
 public function getStatus()
 {
 return $this->status;
 }

 /**
 * Set detected
 *
 * @param string $detected
 * @return Maintenance
 */
 public function setDetected($detected)
 {
 $this->detected = $detected;
 return $this;
 }

 /**
 * Get detected
 *
 * @return string
 */
 public function getDetected()
 {
 return $this->detected;
 }

 /**
 * Set maintenanceNote
 *
 * @param string $maintenanceNote
 * @return Maintenance
 */
 public function setMaintenanceNote($maintenanceNote)
 {
 $this->maintenanceNote = $maintenanceNote;
 return $this;
 }

 /**
 * Get maintenanceNote
 * @return string
 */
 public function getMaintenanceNote()
 {
 return $this->maintenanceNote;
 }

 /**
 * Set tool
 *
 * @param \BaseCrud\Entity\Tool $tool
 * @return Maintenance
 */
 public function setTool(\BaseCrud\Entity\Tool $tool = null)
 {
 $this->tool = $tool;
 return $this;
 }

 /**
 * Get tool
 *
 * @return \BaseCrud\Entity\Tool
 */
 public function getTool()
 {
 return $this->tool;
 }

 /**
 * Set user
 *
 * @param \BaseCrud\Entity\User $user
 * @return Maintenance
 */
 public function setUser(\BaseCrud\Entity\User $user = null)
 {
 $this->user = $user;
 return $this;
 }

 /**
 * Get user
 *
 * @return \BaseCrud\Entity\User
 */
 public function getUser()
 {
 return $this->user;
 }
}

A mio parere la soluzione ideale è utilizzare questa strategia solo per i crud semplici, diciamo che ogni applicazioni ne ha alcuni, questo semplifica di molto l’aggiornamento di un campo, perchè da un solo oggetto sarà possibile modificare sia che so la lunghezza del dato nel database che il validatore del form, mantenendo velocemente tutto sincronizzato.
Per i form più complessi invece consiglio di costruirli separatamente rispetto all’entità perchè potreste guadagnare solo complicazioni.

In questa action costruiremo il form e cercheremo di popolarlo utilizzando l’Hydrator messo a disposizione dal Modulo DoctrineORMModule, che si impegna a semplificare l’integrazione nell’entity, ed in più ho scritto una Strategy Custom, per la gestione dei campi data, per il semplice motivo che le entity di tipo date restituiscono degli oggetti DateTime, mentre l’elemento date di Zend Form con una stringa.

<?php
namespace BaseCrud\Stdlib\Hydrator\Strategy;
use Zend\Stdlib\Hydrator\Strategy\StrategyInterface;
use Zend\Validator\Date;
class DateStrategy
implements StrategyInterface
{
 /**
 * (non-PHPdoc)
 * @see Zend\Stdlib\Hydrator\Strategy.StrategyInterface::extract()
 */
 public function extract($value)
 {
 if($value instanceof \DateTime){
 return $value->format('Y-m-d');
 }
 }

/**
 * (non-PHPdoc)
 * @see Zend\Stdlib\Hydrator\Strategy.StrategyInterface::hydrate()
 */
 public function hydrate($value)
 {
 $validator = new Date(array('format' => 'Y-m-d'));
 if($validator->isValid($value)){
 return new \DateTime(date('Y-m-d', strtotime($value)));
 }
 }
?>

A questo punto vi propongo due action, la prima per la costruzione del form, con un eventuale “idratazione”di dati nel caso si trattasse di una modifica, in questo caso utilizzo DoctrineEntity, un Hydrator che mette a disposizione DoctrineORMModule per semplificare questo tipo di passaggio, soprattutto nel nostro caso, in cui mappiamo direttamente sopra un entità è quindi la corrispondenza tra i due è alta, l’AnnotationBuilder è una classe di Zend\Form che interpreta le annotazioni con cui abbiamo scritto il form per generare la struttura che poi possiamo impaginare in una classica view.

/**

* {@inheritDoc}

*/

public function formAction()

{

$builder = new AnnotationBuilder();

$form = $builder->createForm('BaseCrud\Entity\Maintenance');

$form->setAttribute('action', "/db/maintenance/save/{$this->params('id')}");

if($this->params('single')){

$service = $this->getServiceLocator()->get('baseCrud.service.maintenance');

$hyd = new DoctrineEntity($this->getServiceLocator()->get('Doctrine\ORM\EntityManager'),'BaseCrud\Entity\Maintenance');

$hyd->addStrategy('dataMaintenance', new StrategyDate());

$form->setHydrator($hyd);

$form->bind($service->find($this->params('single')));

}

$form->add(array(

'type' => 'submit',

'name' => 'submitMan',

'attributes' => array(

'class' => 'btn',

'value' => 'Procedi'

)

));

return new ViewModel(array(

'form' => $form

));

}

In questa action invece salvo i dati all’interno di un database, utilizzo il service Manager per mantenere integra la classe che ti gestisce le query fatte al database, in questo modo volessi loggare solo alcuni query potrei comodamente gestire il singolo caso, utilizzo come Hydrator il ClassMethod, aggiungendo come sopra le strategie, vi ricordo che il nome della strategy $hyd->addStratetgy(‘name’, class); corrisponde al setter e getter impostato, in caso di getName e setName il nome della strategi dovrebbe essere ‘name’ appunto..

public function saveAction()

{

$builder = $this->getServiceLocator()->get('baseCrud.annotationBuilder');

$form    = $builder->createForm('BaseCrud\Entity\Maintenance');

$request = $this->getRequest();

if ($request->isPost()) {

$loanService = $this->getServiceLocator()->get('baseCrud.service.maintenance');

$form->setData($request->getPost());

if ($form->isValid()) {

$hydrator = new ClassMethods();

$hydrator->addStrategy('dataMaintenance', new StrategyDate());

$params = $request->getPost();

if($params['id'])

$originalEntity = $loanService->find($params->id);

else {

$toolS = $this->getServiceLocator()->get('baseCrud.service.tool');

$originalEntity = new Maintenance();

$originalEntity->setTool($toolS->find($this->params('id')));

}

$hydrator->hydrate((array)$params, $originalEntity);

$loanService->save($originalEntity);

return $this->redirect()->toRoute('db', array(

'controller'=> 'tool',

'action' => 'single',

'id' => $this->params('id')

));

} else {

var_dump($form->getMessages());

}

}

return false;

}

Con questo chiudo, come vedere le classi che vi ho scritto arrivano da un progetto che sto attualmente sviluppando, quindi sotto mano avete un esempio pratico, con i suoi pregi ed i suoi difetti, ci sono dei var_dump che non dovrebbero esserci, ma sono in sviluppo è normale.. spero possiate comunque trarre qualche interessante spunto da questa condivisione.

Spassionato consiglio che mi sento di condividere con voi è l’utilizzo delle interfacce, particolare classe php di pura descrizione, questa non contiene altro che i nomi delle funzioni, con i parametri necessari per il loro funzionamento la doc, ed ha come proprietà fondamentale la necessaria totale implementazione per funzionare correttamente.

Se sbagliamo il nome di una funzione, un parametro utilizzato nell’implementazione non rispetta l’interfaccia, questa segnalerà un errore, facile capire l’enorme vincolo ma anche la forza quando si tratta di definire uno standard.

Insomma mi avete scoperto! L’interfaccia è un argomento fin troppo banale, cos’è, cosa fa, lo sanno tutti, è lo scopo che non è mai chiaro o meglio, lo conoscono tutti ma raggiungerlo non è facile! Lo standard per un azienda, ma anche per un proprio ordine mentale è indispensabile! Sapere che una certa operazione si fa in un certo modo vuol dire risparmiare tempo di realizzazione e di studio, i design pattern non sono altro che standard “certificati” 10+ insomma!

Risparmiare tempo nell’evitare di ripensare le stesse cose vuol dire aver tempo per rinnovare, per studiare o per riscrivere codice, implementare interfacce vuol dire avere la sicurezza che ci sia un punto di partenza spoglio di logica quindi molto più facile da leggere, da cui partire per capire come funziona un programma se queste interfacce fossero condivise anche tra prodotti aziendali, cosa consigliata, si avrà la possibilità di entrare in un progetto iniziato da colleghi senza il timore di non capire nulla o di metterci troppo tempo.

In caso di grandi Team può essere complessa la definizione di un interfaccia, ma come potrebbero dire i Fan Boy della Apple il minimal potrebbe essere la soluzione ideale, evitiamo di rendere tutto sovra strutturato perchè potrebbe voler dire, sopratutto in condizioni di scarso utilizzo di questa pratica in precedenza, un eccessiva limitazione d’uso portando il tutto nel dimenticatoio, perchè dobbiamo tenere a mente che la buona programmazione deve sempre e comunque in ambito di lavoro portare i suoi frutti, lo stipendio insomma.

Abbiamo parlato spesso del Moduli di zend Framework 2, ormai sappiamo che l’obiettivo di questo scelta fatta dagli sviluppatori del Framework è il riutilizzo del codice, uno dei primi dubbi che mi è venuto è dove metto gli asset? I file statici come per esempio css, js, editor come posso gestirli? Un modulo che ci aiuta a risolvere questo problema è l’AssetManager.

é molto semplice, ci permette di specificare una nuova cartella che si va ad aggiungere alla public di default, quindi quella che contiene gli asset dell’intera applicazione garantendoci quindi che anche questi file del modulo possa venir letti senza esser spostati.

Io lo utilizzo all’interno di GaBlog, il Modulo che sto sviluppando per la gestione di un Blog con Zend Framework, tra gli sviluppatori ci sono volti noti ed è testato con PhpUnit quindi potete utilizzarlo senza troppe preoccupazioni. Ovviamente rimanete in contatto con il progetto per seguirne gli aggiornamenti.

$post = new Post();
$post->setDateTimeCreated(new \DateTime(date('Y-m-d G:m:s')));
$post->setTitle($data['title']);
$post->setContent($data['content']);
$post->setDescription($data['description']);
$post->setTag($data['tag']);
$post->setCategory($data['category']);
$post->setUser($data['user']);
$post->setStatus($data['status']);

Direi che le colonne qui sopra parlano da se, il risparmio di codice lo noterebbe chiunque, l’Hydrator è un oggetto utile ad idratare, riempire o popolare ditelo come volete un altro oggetto.
In Zend Framework 2 ci sono varie classi che possiamo utilizzare sotto il namespace Hydrator, la più classiche quella che ho utilizzato in questo esempio è il ClassMethods se no esiste la ArraySerializable, oppure è possibile creare un proprio Hydrator personalizzato estendendo la classe AbstractHydrator oppure implementando l’interfacci HydratorInterface.

Sull’importanza dei moduli in Zf2 abbiamo già parlato molto in questo blog, quindi è finalmente il momento di iniziare a toccare con mano quelli che sono i moduli non dico certificati, ma dei quali non potete fare a meno o più semplicemente quelli che posso consigliarvi in quanto scritti bene e strutturati nel modo migliore.

Primo tra tutti è ZfcUser, non solo perchè è uno dei primi ad esser stati scritti, ma anche perchè è stato ideato dalla Zf-Commons, un tram di developer composto in primis da nomi cone Rob Allen, Evan, Matthew ed altri del team di zf, questo per dirvi che la qualità non può che essere ottima.

In secondo luogo è uno dei componenti che in un sito non può mancare, questo modulo gestisce la registrazione ed il login degli utenti, fornendovi i metodi base per avere gestire un area riservata e far registrare gli utenti al vostro sito.

Infatti tra i principali metodi possiamo leggere

loginAction
logoutAction
authenticateAction
registerAction

ma anche action per il recupero password e via dicendo.
Utilizza la DI e il service Locator quindi è morto facile estenderlo ed adattarlo alle proprie esigenze.
Cosa aspettate a provarlo?

php composer.phar require  zf-commons/zfc-user: dev-master

Php è un template engine! Twig è un template Engine in Php, ma innanzi tutto un template Engine è un elemento del vostro applicativo, ammesso che vogliate fare un lavoro ben fatto.. Usando l’MVC e cercando di non dare codice troppo complesso a quella categoria di strani personaggi che usano molto il mouse e poco la tastiera, ma soprattutto ancor meno la console che chiamiamo Web Designer.

Ha come compito quello di semplificare al massimo il codice operativo, quello non inerente alla vista, per intendersi limita la presenza di php lasciando solo l’HTML, CSS e Js ed in più mette a disposizione costrutti utili ed essenziali per gestire la vista, permettendovi per esempio di inviarle in blocco ai Web Designer senza portarsi dietro tutto l’applicativo del quale il grafico non se ne fa nulla.

Nel panorama php uno di più famosi Template Engine è Twig, integrato in Symfony personalmente l’ho utilizzato in un solo progetto, un app Facebook molto basic usando come Framework Silex utile a gestire l’iscrizione ad una newsletter. Mette a disposizione una sintassi molto facile con i principali costrutti, selezione e cicli ma anche funzioni più interessanti e dedicate come i filtri sulle date, l’autoescape e molto altro che potete trovare nella doc, molto facile e completa.

Zend invece ha fatto una scelta diversa e forse più ovvia, con la quale io mi trovo molto bene, perchè semplicemente non necessita di null’altro che il Php, che nasce come template Engine ed è ovviamente molto potente anche in questo senso, soprattutto se possiamo avere la padronanza del php.ini e quindi siamo in grado di attivare gli Short Tag, che rendono il template ancora migliore, <?=$content?> ne è un esempio più che lampante. Se volete utilizzare Twig anche in un progetto zend però provate questo modulo, potrebbe aiutarvi!

Quindi valutate bene se utilizzare un template Engine come Twig quando si ha a disposizioni senza portarsi dentro altre librerie uno strumento come il Php.

In merito una simpatica discussione su Google Plus nella community dedicata al Php.

Argomento ormai trattato da tutti ed in tutte le salse, allo ZfDay i moduli ne hanno fatto da padrone, gestione degli utenti, Acl integrazione con Doctrine e chi più che ha più ne metta.

I Moduli sono un estensione del Pattern MVC che consentono di gestire meglio ed in modo più completo il codice pacchettizzandolo nell’ottica del riutilizzo del codice, se pensiamo ai moduli come componenti, servizi o funzionalità che possono vivere di vita proprio, capiamo subito che abbiamo tra le mani non solo uno dei concetti, insieme agli Eventi alla DI e al service Locator fondamentali di zend framework 2, ma anche uno strumento molto forte per rendere il nostro codice riutilizzabili semplicemente.

Sembra facile a dirsi, ma quando mettiamo le mani in un modulo, soprattutto nell’ottica di rilasciarlo Open Source, dobbiamo pensarlo ad un livello di astrazione molto alto, per il semplice fatto che deve essere estendibile e riutilizzabile da persone che probabilmente potrebbero farne un uso diverso dal nostro.

Usiamo il file di configurazioni, consapevoli del fatto che in base all’ordine di dichiarazione del modulo potranno tranquillamente essere sovrascritte e quindi contribuiranno a rendere il Modulo ancora più flessibile.

Per installare questi moduli possiamo utilizzare quello che ormai sta diventando lo standard per i programmatori, ovvero composer, ma lo stesso git, fornisce il comando submodule per gestire al meglio questi pacchetti. In più per reperire queste funzionalità la Zend ha messo a disposizione un sito dedicato, a dimostrazione di quanto questi siano fondamentali, visitatelo.

Ovviamente non tutto è oro, cercate di controllare sempre la fonte, il programmatore o la community che ha sviluppato quella funzionalità in modo da evitare quelli di bassa lega diciamo, attualmente è molto facile caricare sul sito i propri moduli, basta inserire il link del repository Github e di conseguenza la qualità potrebbe essere scarsa, è sbagliata prendere moduli senza controllarli, quando sarebbe sbagliato reinventare la ruota ogni volta che si vuole creare un pannello di Login per gli utenti, controlliamo il modulo, ma apriamoci e riutilizziamo i moduli che troviamo e che scriviamo.

I miei attuali moduli – GABLOG – GAGOOGL

Doctrine 2, Zend Framework 2, DoctrineORMModule unisce un ORM ad un Framework, ed io parlando la lingua dei Noob, teneterò di spiegarlo ma soprattutto spiegarmelo, in modo da poterlo configurare la prossima volta velocemente e senza disturbare nessuno.

Innanzi tutto, Skeleton Application.

git clone git@github.com:zendframework/ZendSkeletonApplication.git

Apriamo il file composer.json e modifichiamo in modo da avere una cosa come questa

Buongiorno! In questo week end di freddo e malattia ho deciso di provare SlideShare, cosa ci sarà di interessante dite voi? Nulla!

Ma non potevo saperlo, quindi armato di Silex e LibreOffice ho scritto la bellezza di 15 Slide che parlano di questo Micro Framework che ormai ha conquistato parte di me. Progettino semplice, uno skeleton di un applicazione fatta in Silex.