[Part 2] - Pagina contatto: validatori, Forms and Emailing¶
Panoramica ¶
Ora abbiamo i template HTML di base a posto, andiamo a fare una pagina funzionale. Inizieremo con una delle pagine più semplici; La pagina di contatto. Alla fine di questo capitolo si avrà una pagina di contatto che permette agli utenti di inviare le richieste contattare il webmaster. Tali richieste saranno inviate al webmaster.
Le seguenti aree verranno dimostrate in questo capitolo:
- Validatori
- Forms
- Impostazione dei valori di configurazione del bundle
Pagina Contatti¶
Routing¶
Come per la pagina About che abbiamo creato nell'ultimo capitolo, inizieremo con la definizione del percorso pagina dei contatti. Aprire il fileBloggerBlogBundle che si trova in src / Blogger / BlogBundle / Resources / config / routing.yml e aggiungere la seguente regola di routing.
# src/Blogger/BlogBundle/Resources/config/routing.yml
BloggerBlogBundle_contact:
pattern: /contact
defaults: { _controller: BloggerBlogBundle:Page:contact }
requirements:
_method: GET
Non c'è niente di nuovo qui, la regola corrisponde al percorso / contatto , per ilmetodo HTTP GET che esegue l' azione contact della pagina controller nel BloggerBlogBundle .
Controller¶
Dopo dobbiamo aggiungere l'azione contact per la pagecontroller in BloggerBlogBundle che si trova in src / Blogger / BlogBundle / Controller / PageController.php .
// src/Blogger/BlogBundle/Controller/PageController.php
// ..
public function contactAction()
{
return $this->render('BloggerBlogBundle:Page:contact.html.twig');
}
// ..
Per ora l'azione è molto semplice, rende solo la visualizzazione della pagina di contatto. Torneremo in seguito al controller.
View¶
Creare la visualizzazione della pagina di contatto in src / Blogger / BlogBundle / Resources / views / Page / contact.html.twig e aggiungere il seguente contenuto.
{# src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig #}
{% extends 'BloggerBlogBundle::layout.html.twig' %}
{% block title %}Contact{% endblock%}
{% block body %}
<header>
<h1>Contact symblog</h1>
</header>
<p>Want to contact symblog?</p>
{% endblock %}
Anche questo template è abbastanza semplice.Estende il modello di layout BloggerBlogBundle, dove prevale il blocco del titolo per impostare un titolo personalizzato e definisce alcuni contenuti per il blocco del corpo.
Collegamento alla pagina ¶
Infine abbiamo bisogno di aggiornare il link nel template base.html.twig in / app / views / Resources base.html.twig per collegarsi alla pagina dei contatti.
<!-- app/Resources/views/base.html.twig -->
{% block navigation %}
<nav>
<ul class="navigation">
<li><a href="{{ path('BloggerBlogBundle_homepage') }}">Home</a></li>
<li><a href="{{ path('BloggerBlogBundle_about') }}">About</a></li>
<li><a href="{{ path('BloggerBlogBundle_contact') }}">Contact</a></li>
</ul>
</nav>
{% endblock %}
Se si punta il browser a http://symblog.dev/app_dev.php/ e cliccate sul link contatto nella barra di navigazione, si dovrebbe vedere una pagina di contatto molto semplice. Ora abbiamo la pagina correttamente impostata, è tempo di iniziare a lavorare sul form di contatto. Questo è suddiviso in 2 parti distinte; i validatori e il form. Prima di poter affrontare il concetto di validatori e il form abbiamo bisogno di pensare a come gestire i dati della richiesta di contatto.
Contact Entity¶
Iniziamo con la creazione di una classe che rappresenta una richiesta di contatto da un utente. Vogliamo intercettare alcune informazioni di base come il nome,l'email,l' oggetto e il corpo del messaggio. Creare un nuovo file in src / Blogger / BlogBundle / Entità / Enquiry.php e incollare il seguente contenuto.
<?php
// src/Blogger/BlogBundle/Entity/Enquiry.php
namespace Blogger\BlogBundle\Entity;
class Enquiry
{
protected $name;
protected $email;
protected $subject;
protected $body;
public function getName()
{
return $this->name;
}
public function setName($name)
{
$this->name = $name;
}
public function getEmail()
{
return $this->email;
}
public function setEmail($email)
{
$this->email = $email;
}
public function getSubject()
{
return $this->subject;
}
public function setSubject($subject)
{
$this->subject = $subject;
}
public function getBody()
{
return $this->body;
}
public function setBody($body)
{
$this->body = $body;
}
}
Come si può vedere questa classe definisce solo alcune variabilii protette e le funzioni di accesso per queste. Qui non c'è nulla che definisce un modo per la validazione dei membri, o come questi sono relazionati con il form. Torneremo su questo più avanti.
Note
Diamo uno sguardo veloce per parlare dei namespaces in Symfony2. La classe entity che abbiamo creato impostando namespace a Blogger\BlogBundle\Entity. Come Symfony2 autocarica il supporto PSR-0 standard la directori namespace mappa il Bundle con la struttura delle cartelle. La Enquiry entity class localizzata in src/Blogger/BlogBundle/Entity/Enquiry.php assicura per Sy2 di poter autocaricare correttamente la classe.
Come può Sy2 autocaricare e conoscere Blogger namespace che si trova nella directori src ? Questo grazie alla configurazione dell' autoloader in app/autoloader.php
// app/autoloader.php
$loader->registerNamespaceFallbacks(array(
__DIR__.'/../src',
));
Questo $loader registra uno spazio per i namespaces non ancora registrati .Come il Blogger namespace che non è registrato, il caricatore Symfony2 cercherà i file richiesti nella directori src.
Autoloading e namespace sono un concetto molto potente in Symfony2. Se si hanno degli errori in cui PHP non è in grado di trovare le classi, è probabile che l'errore sia in namespace o nella struttura delle cartelle. Controllate anche se namespace è stato registrato con autoloader come mostrato sopra. Non si dovrebbe essere tentati di risolvere questo utilizzando le funzioni PHP
require o include.
Forms¶
Successivamente creeremo il form. Symfony2 viene fornito con un componente per la creazione di form molto potente che facilita il compito di impostare il form. Come per tutti i componenti Symfony2 anche questo può essere utilizzato al di fuori di Symfony2 nei vostri progetti. La sorgente Component Form è disponibile su Github. Inizieremo con la creazione di una classe AbstractType che rappresenta il modulo di richiesta. Avremmo potuto creare il modulo direttamente nel controller e non perdere tempo con questa classe, tuttavia separare il form nella propria classe ci permette di riutilizzare il form in tutta l'applicazione. Inoltre, impedisce dii riempire il controller. Dopo tutto, il controller dovrebbe essere semplice. Con 'lo scopo di fornire solo il collante tra il modello e la vista.
EnquiryType¶
Create un nuovo file in src/Blogger/BlogBundle/Form/EnquiryType.php e aggiungete questo contenuto..
<?php
// src/Blogger/BlogBundle/Form/EnquiryType.php
namespace Blogger\BlogBundle\Form;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilder;
class EnquiryType extends AbstractType
{
public function buildForm(FormBuilder $builder, array $options)
{
$builder->add('name');
$builder->add('email', 'email');
$builder->add('subject');
$builder->add('body', 'textarea');
}
public function getName()
{
return 'contact';
}
}
La classe EnquiryType introduce la classe FormBuilder . La classe FormBuilder è il tuo migliore amico quando devi creare un form.È in grado di semplificare il processo di definizione campi con i metadati dati al campo stesso. Quindi noi avevamo Enquiry entity molto semplice non avevamo ancora impostato i metadata, di default vengono impostati a campi tipo imput text..Questo è buono per molti campi eccetto body dove necessitiamo di una textarea, e email dove vogliamo approfittare dei nuovi email input type di HTML5.
nota
Un punto fondamentale da ricordare è che la funzione getName deve restituire un identificatore univoco.
Creating the form in the controller¶
Ora abbiamo definito le classi Enquiry entity and EnquiryType, e possiamo aggiornare la contact action per usarle. Sostituire il contenuto della contact action in src/Blogger/BlogBundle/Controller/PageController.php con il seguente..
// src/Blogger/BlogBundle/Controller/PageController.php
public function contactAction()
{
$enquiry = new Enquiry();
$form = $this->createForm(new EnquiryType(), $enquiry);
$request = $this->getRequest();
if ($request->getMethod() == 'POST') {
$form->bindRequest($request);
if ($form->isValid()) {
// Perform some action, such as sending an email
// Redirect - This is important to prevent users re-posting
// the form if they refresh the page
return $this->redirect($this->generateUrl('BloggerBlogBundle_contact'));
}
}
return $this->render('BloggerBlogBundle:Page:contact.html.twig', array(
'form' => $form->createView()
));
}
Iniziamo con la creazione di un istanza per Enquiry entity. Questa rappresenta i dati per una richiesta di contatto. Dopo di che creiamo il form . Dove specifichiamo il tipo di campo con EnquiryType creata in precedenza , e poi gli passiamo il nostror enquiry entity oggetto.Il metodo createForm può usare questi 2 blueprints per creare una rappresentazione di form..
Dato che questa azione di controllo si occuperà della visualizzazione e l'elaborazione del form inviato, abbiamo bisogno di controllare il metodo HTTP. I form inviati vengono inviati normalmente tramite POST , e il nostro form non farà eccezione.. Se il metodo di richiesta è POST, una chiamata a bindRequest trasformerà i dati in menbri del nostro oggetto $enquiry . A questo punto il nostro oggetto $enquiry potrà essere rinviato nuovamente..
Più avanti facciamo un controllo per vedere se il modulo è valido. Sicome non abbiamo specificato nessun validatore ancora, il modulo sarà sempre valido.
Infine dobbiamo specificare il form per il rendering. Si noti che stiamo passando anche una rappresentazione della vista . Questo oggetto ci permette di rendere il form alla vista
Siccome abbiamo usato 2 nuove classi nel nostro controller abbiamo bisogno di importare i namespacei. Aggiornare il file controller che si trova in src / Blogger / BlogBundle / Controller / PageController.php con il seguente.. Le dichiarazioni devono essere messe sotto l'esistente dichiarazione use .......
<?php
// src/Blogger/BlogBundle/Controller/PageController.php
namespace Blogger\BlogBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
// Import new namespaces
use Blogger\BlogBundle\Entity\Enquiry;
use Blogger\BlogBundle\Form\EnquiryType;
class PageController extends Controller
// ..
Rendering the form¶
Grazie ai metodi di Twig il rendering dei form è molto semplice. Twig fornisce un sistema stratificato per il rendering del form che permette di rendere il form come una intera entità, o come singoli errori e singoli elementi, a seconda del livello di personalizzazione richiesto.
Per dimostrare la potenza dei metodi di Twig possiamo utilizzare il seguente frammento di redering per l'intero modulo.
<form action="{{ path('BloggerBlogBundle_contact') }}" method="post" {{ form_enctype(form) }}>
{{ form_widget(form) }}
<input type="submit" />
</form>
Mentre questo è molto utile per form semplici ha però i suoi limiti quando sono necessarie personalizzazioni estese , che è spesso il caso con i form.
Per il nostro form di contatto, si opterà per una via di mezzo. Sostituire il codice del template in src / Blogger / BlogBundle / Resources / views / Page / contact.html.twig con il seguente.
{# src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig #}
{% extends 'BloggerBlogBundle::layout.html.twig' %}
{% block title %}Contact{% endblock%}
{% block body %}
<header>
<h1>Contact symblog</h1>
</header>
<p>Want to contact symblog?</p>
<form action="{{ path('BloggerBlogBundle_contact') }}" method="post" {{ form_enctype(form) }} class="blogger">
{{ form_errors(form) }}
{{ form_row(form.name) }}
{{ form_row(form.email) }}
{{ form_row(form.subject) }}
{{ form_row(form.body) }}
{{ form_rest(form) }}
<input type="submit" value="Submit" />
</form>
{% endblock %}
Come potete vedere, usiamo 4 nuovi metodi Twig per rendere il form.
Il primo metodo form_enctype imposta il tipo di contenuto del form. Questo deve essere impostato quando il form si occupa di ricaricare file. La buona pratica , dice sempre di utilizzare questo su tutti i form nel caso in cui è possibile aggiungere il caricamento di file in futuro. Debug di un form che gestisce il caricamento di file senza alcun tipo di contenuto impostato può essere un rompicapo.
Il secondo metodo form_errors renderà eventuali errori del form nel caso in cui la convalida non è riuscita.
Il terzo metodo form_row emette gli elementi interi relativi ad ogni campo del form. Questo include gli eventuali errori per il campo, l'etichetta del campo e l'elemento di campo effettivo.
Infine usiamo ilmetodo form_rest. E 'sempre una mossa sicura per utilizzare questo metodo alla fine del form per rendere tutti i campi che potreste aver dimenticato, tra cui i campi nascosti e il modulo di Symfony2 CSRF token.
Nota
Cross-Site Request Forgery (CSRF) è spiegato in dettaglio nel capitolo Form del libro Symfony2.
Styling the form¶
Se si visualizza il form di contatto ora con http://symblog.dev/app_dev.php/contact noterete non sembra molto attraente. Andiamo ad agginungere aggiungere alcuni stili per migliorare questo aspetto. Poiché gli stili sono specifici per il form all'interno del nostro Bundle Blog creeremo gli stili in un nuovo foglio di stile all'interno dello stesso bundle. Creiamo un nuovo file in src / Blogger / BlogBundle / Resources / public / css / blog.css e incolliamo il seguente contenuto.t.
.blogger-notice { text-align: center; padding: 10px; background: #DFF2BF; border: 1px solid; color: #4F8A10; margin-bottom: 10px; }
form.blogger { font-size: 16px; }
form.blogger div { clear: left; margin-bottom: 10px; }
form.blogger label { float: left; margin-right: 10px; text-align: right; width: 100px; font-weight: bold; vertical-align: top; padding-top: 10px; }
form.blogger input[type="text"],
form.blogger input[type="email"]
{ width: 500px; line-height: 26px; font-size: 20px; min-height: 26px; }
form.blogger textarea { width: 500px; height: 150px; line-height: 26px; font-size: 20px; }
form.blogger input[type="submit"] { margin-left: 110px; width: 508px; line-height: 26px; font-size: 20px; min-height: 26px; }
form.blogger ul li { color: #ff0000; margin-bottom: 5px; }
Dobbiamo far sapere alll'applicazione che vogliamo usare questo foglio di stile. Potremmo importare il foglio di stile nel form di contatto, ma potremmo dover utilizzare questo foglio di stile in seguito, ha senso importarlo nel layout BloggerBlogBundle che abbiamo creato nel capitolo 1. Aprire il BloggerBlogBundle in src / Blogger / BlogBundle / resources / views / layout.html.twig e sostituirlo con il seguente contenuto.
{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}
{% extends '::base.html.twig' %}
{% block stylesheets %}
{{ parent() }}
<link href="{{ asset('bundles/bloggerblog/css/blog.css') }}" type="text/css" rel="stylesheet" />
{% endblock %}
{% block sidebar %}
Sidebar content
{% endblock %}
Si può vedere che abbiamo definito un blocco di foglio di stile per eseguire l'override del blocco foglio di stile definito nel modello genitore. Tuttavia, è importante notare la chiamata al metodo genitore. Questo importa il contenuto dal blocco fogli di stile nel modello di genitore in app / Resources / base.html.twig , e ci permette di aggiungere il nostro nuovo foglio di stile. Dopo tutto, non vogliamo sostituire i fogli di stile esistenti.
Affinché la funzione asset colleghi correttamente la risorsa che dobbiamo copiare o collegare al bundle nella cartella web. Ciò può essere fatto con i seguenti
$ php app/console assets:install web --symlink
Nota
Se si utilizza un sistema operativo che non supporta i link simbolici, comei Windows, si deve far arrivare l'opzione link simbolico come segue.
php app/console assets:install web
Questo metodo in realtà copia le risorse dei bundle pubblico nella cartella i web dell'applicazione. Poiché i file vengono copiati in realtà, sarà necessario eseguire questa operazione ogni volta che si apporta una modifica a una risorsa del bundlei pubblico.
Ora, se si aggiorna la pagina dei contatti il form avrà un nuovo stile..
Nota
Mentre la funzione asset fornisce le funzionalità di cui abbiamo bisogno per utilizzare le risorse, c'è una soluzione migliore per questo. Assetic libreria Kris Wallsmith è fornito in bundle con la distribuzione standard di Symfony2 per impostazione predefinita. Questa libreria fornisce gestione patrimoniale ben oltre le normali capacità Symfony2. Assetic ci permette di eseguire i filtri sulle attività di combinare automaticamente, minify e gzip . E 'inoltre possibile eseguire filtri di compressione sulle immagini. Assetic ci consente inoltre di fare riferimento a risorse direttamente all'interno della cartella bundle pubblico senza dover eseguire il comando assets:install. Esploreremo l'uso di Assetic nei capitoli successi
La mancata presentazione ¶
I più impazienti potrebbero aver già provato a inviare il modulo per essere accolti con un errore Symfony2.
Questo errore ci sta dicendo che non c'è rotta chei corrisponde a / contact con il metodo HTTP POST. Il percorso accetta solo le richieste GET e HEAD. Questo perché abbiamo configurato il nostro percorso con l'esigenza del metodo GET.
Andiamo ad aggiornare il percorso di contatto in src / Blogger / BlogBundle / Resources / config / routing.yml per consentire anche richieste POST.
# src/Blogger/BlogBundle/Resources/config/routing.yml
BloggerBlogBundle_contact:
pattern: /contact
defaults: { _controller: BloggerBlogBundle:Page:contact }
requirements:
_method: GET|POST
Nota
Ci possiamo chiedere perché il percorso permette il metodo GET HEAD solo quando è stato specificato. Questo perché HEAD è una richiesta GET, ma solo le intestazioni HTTP vengono restituiti.
Ora, quando si invia il modulo questo andrà a funzionare come previsto, anche se in realtà non dovrebbe fare molto ancora. La pagina solo reindirizzerà di nuovo al modulo di contatto.
Validators¶
Il componente validatore di Sy2 ci permette di eseguire il compito di convalida dei dati. La convalida è un compito comune quando si tratta di dati da form. La convalida deve inoltre essere eseguita sui dati prima che venga sottoposto ad un database. Il validatore Symfony2 ci consente di separare la logica di convalida lontano dai componenti che possono utilizzarla, come ad esempio il componente form o il componente Database. Questo approccio significa che abbiamo un insieme di regole di convalida per un oggetto.
Cominciamo con l'aggiornamento di Enquiry entity in src / Blogger / BlogBundle / Entità / Enquiry.php per specificare alcuni validatori. Assicurarsi di aggiungere i 5 nuovi use dichiarazioni nella parte superiore del file.
<?php
// src/Blogger/BlogBundle/Entity/Enquiry.php
namespace Blogger\BlogBundle\Entity;
use Symfony\Component\Validator\Mapping\ClassMetadata;
use Symfony\Component\Validator\Constraints\NotBlank;
use Symfony\Component\Validator\Constraints\Email;
use Symfony\Component\Validator\Constraints\MinLength;
use Symfony\Component\Validator\Constraints\MaxLength;
class Enquiry
{
// ..
public static function loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('name', new NotBlank());
$metadata->addPropertyConstraint('email', new Email());
$metadata->addPropertyConstraint('subject', new NotBlank());
$metadata->addPropertyConstraint('subject', new MaxLength(50));
$metadata->addPropertyConstraint('body', new MinLength(50));
}
// ..
}
Per definire i validatori dobbiamo attuare il metodo statico loadValidatorMetadata . Questo ci fornisce un oggetto ClassMetadata . Possiamo utilizzare questo oggetto per impostare vincoli di proprietà sui nostri membri entity. La prima dichiarazionei applica il vincolo NotBlank al membro name . Il validatore NotBlank è semplice come sembra, restituirà solo true se il valore è la convalida non è vuota. Poi abbiamo la convalida di configurazione per il membro email. Il servizio Symfony2 Validator prevede un validatore per e-mail che saprà anche controllare i record MX per assicurare la convalida. Sul membro subject vogliamo impostare un NotBlank e un MaxLength. È possibile applicarepiù validatori ad un solo membro.
Un elenco completo dei vincoli di validazione è disponibile nelle Symfony2 documenti di riferimento. È inoltre possibile creare validatori personalizzati .
Ora, quando si invia il modulo di contatto, i dati forniti saranno trasmessi attraverso i vincoli di convalida. Provate a digitare un indirizzo email non valido. Dovreste vedere un messaggio di errore che informa che l'indirizzo email non è valido. Ogni validatore fornisce un messaggio predefinito che può essere ignorato, se necessario. Per cambiare il messaggio di output dal validatore email è necessario effettuare le seguenti operazioni.
$metadata->addPropertyConstraint('email', new Email(array(
'message' => 'symblog does not like invalid emails. Give me a real one!'
)));
Nota
Se si utilizza un browser che supporta HTML5 è probabile che usciranno dei messaggi HTML5 per far rispettare determinati vincoli. Questa è la validazione lato client e Symfony2 fisserà vincoli HTML5 idonei, sulla base di Entity metadati. Potete vedere questo sull'elemento email. Il codice HTML di uscita è
<input type="email" value="" required="required" name="contact[email]" id="contact_email">
Abbiamo usato uno dei nuovi campi di input e-mail di tipo HTML5, e fissato l'attributo richiesto. La validazione lato client è buona in quanto non richiede un round trip al server per convalidare il formulario. Tuttavia, la convalida lato client non deve essere utilizzata da sola Si deve sempre convalidare i dati dal lato server , in quanto è abbastanza facile per un utente di by-passare la validazione lato client..
Invio di e-mail ¶
Mentre il nostro modulo di contatto permetterà agli utenti di inviare richieste di informazioni, ma ancora non succede niente .Andiamo ad aggiornare il controller per inviare una e-mail al webmaster blog. Symfony2 viene completo con la libreria Swift Mailer per l'invio di email. Swift Mailer è una libreria molto potente, qui useremo solo una piccola parte,di ciò che questa libreria può eseguire.
Configurare le impostazioni di Swift Mailer ¶
Swift Mailer è già configurato out of the box per lavorare nella distribuzione Symfony2 Standard, però abbiamo bisogno di configurare alcune impostazioni per quanto riguarda i metodi di invio e le credenziali. Aprire il file di parametri in app / config / parameters.ini e trovare le impostazioni con prefisso mailer_ .
mailer_transport="smtp"
mailer_host="localhost"
mailer_user=""
mailer_password=""
Swift Mailer fornisce una serie di metodi per l'invio di messaggi di posta elettronica, incluso l'utilizzo di un server SMTP, utilizzando una installazione locale di sendmail, o anche utilizzando un account GMail. Per semplicità useremo un account GMail. Aggiornare i parametri con i seguenti, sostituendo il nome utente e la password dove necessario.
mailer_transport="gmail"
mailer_encryption="ssl"
mailer_auth_mode="login"
mailer_host="smtp.gmail.com"
mailer_user="your_username"
mailer_password="your_password"
Avviso
Fate attenzione se si utilizza un sistema di controllo versione (VCS) come Git per il progetto, soprattutto se il repository è pubblico quindi accessibile per vedere il tuo nome utente e la password Gmail . È necessario assicurarsi che il file app / config / parameters.ini venga aggiunto alla lista ignora dei VCS. Un approccio comune a questo problema è cambiare il suffisso del nome del file che contiene le informazioni sensibili, come app / config / parameters.ini con . dist . È quindi fornire valori predefiniti per le impostazioni in questo file e aggiungere il file vero e proprio, vale a dire app / config / parameters.ini aggiungerlo alla lista VCS ignora. Dopo di che distribuiamo il file *. dist con il progetto, cosi si permettere allo sviluppatore di rimuovere l' . dist estensione e inserire le impostazioni necessarie.
Aggiornare il controller ¶
Aggiornare la page controller che si in src / Blogger / BlogBundle / Controller / PageController.php con il contenuto sottostante.
// src/Blogger/BlogBundle/Controller/PageController.php
public function contactAction()
{
// ..
if ($form->isValid()) {
$message = \Swift_Message::newInstance()
->setSubject('Contact enquiry from symblog')
->setFrom('enquiries@symblog.co.uk')
->setTo('email@email.com')
->setBody($this->renderView('BloggerBlogBundle:Page:contactEmail.txt.twig', array('enquiry' => $enquiry)));
$this->get('mailer')->send($message);
$this->get('session')->setFlash('blogger-notice', 'Your contact enquiry was successfully sent. Thank you!');
// Redirect - This is important to prevent users re-posting
// the form if they refresh the page
return $this->redirect($this->generateUrl('BloggerBlogBundle_contact'));
}
// ..
}
Quindi abbiamo utilizzato la libreria Swift Mailer per creare un Swift_Message oggetto , che può essere inviato via email.
Nota
Come la libreria Swift Mailer non usa namespace, abbiamo bisogno del prefisso \ alla classe Swift Mailer . Questo dice a PHP di tornare di nuovo al global space . Avrete bisogno di prefissare tutte le classi e le funzioni che non sono namespace con un \ . Se non avete posizionato il prefisso prima della classe Swift_Message PHP va a cercare nella classe namespace corrente, che in questo esempio è Blogger \ BlogBundle \ controller , causando un errore ..
Abbiamo anche stabilito un messaggio flash nella sessione. I messaggi flash sono messaggi che persistono per esattamente una richiesta. Dopo di che vengono automaticamente puliti da Symfony2. Il messaggio flash verrà visualizzato nel template di contatto per informare l'utente che il form è stato inviato. Come il messaggio flash persiste esattamente solo per una richiesta, sono l'ideale per avvisare l'utente del successo delle precedenti azioni.
Per visualizzare il messaggio flash abbiamo bisogno di aggiornare il template di contatto si in src / Blogger / BlogBundle / Resources / views / Page / contact.html.twig . Aggiornare il contenuto del modello con il seguente
{# src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig #}
{# rest of template ... #}
<header>
<h1>Contact symblog</h1>
</header>
{% if app.session.hasFlash('blogger-notice') %}
<div class="blogger-notice">
{{ app.session.flash('blogger-notice') }}
</div>
{% endif %}
<p>Want to contact symblog?</p>
{# rest of template ... #}
This checks to see if a flash message with the identifier ‘blogger-notice’ is set and outputs it.
Impostazione email webmaster ¶
Symfony2 fornisce un sistema di configurazione che possiamo utilizzare per definire le nostre impostazioni. Useremo questo sistema per impostare l'indirizzo e-mail webmaster piuttosto che codificare l'indirizzo nel controller di cui sopra. In questo modo possiamo facilmente riutilizzare questo valore in altri luoghi senza duplicazione del codice. Inoltre, quando il blog genera tanto traffico di invio dei form diventa molto lavoro per voi da affrontare, si può quindi aggiornare l'indirizzo email per passare le e-mail al vostro assistente. Create un nuovo file in src / Blogger / BlogBundle / Resources / config / config.yml e incollare il seguente codice.
# src/Blogger/BlogBundle/Resources/config/config.yml
parameters:
# Blogger contact email address
blogger_blog.emails.contact_email: contact@email.com
Quando si definiscono i parametri è buona norma rompere il nome del parametro in un numero di componenti. La prima parte dovrebbe essere una versione inferiore del nome del bundle con sottolineatura per separare le parole. Nel nostro esempio abbiamo trasformato il bundle BloggerBlogBundle in blogger_blog . La parte restante del nome del parametro può contenere qualsiasi numero di parti separate dal. (period). Questo ci permette di raggruppare logicamente i parametri.
Affinché l'applicazione Symfony2 utilizzi i nuovi parametri, abbiamo bisogno di importare il file di configurazione nel file principale di configurazione dell'applicazione in app / config / config.yml . Per raggiungere questo obiettivo, aggiorniamo l' import direttiva nella parte superiore del file
# app/config/config.yml
imports:
# .. existing import here
- { resource: @BloggerBlogBundle/Resources/config/config.yml }
Il percorso di importazione è la posizione fisica del file sul disco. La direttiva @ BloggerBlogBundle risolverà il percorso del BloggerBlogBundle che è src / Blogger / BlogBundle .
Infine andiamo ad aggiornare l'azione di contatto per utilizzare il parametro.
// src/Blogger/BlogBundle/Controller/PageController.php
public function contactAction()
{
// ..
if ($form->isValid()) {
$message = \Swift_Message::newInstance()
->setSubject('Contact enquiry from symblog')
->setFrom('enquiries@symblog.co.uk')
->setTo($this->container->getParameter('blogger_blog.emails.contact_email'))
->setBody($this->renderView('BloggerBlogBundle:Page:contactEmail.txt.twig', array('enquiry' => $enquiry)));
$this->get('mailer')->send($message);
// ..
}
// ..
}
Nota
Poiché il file di configurazione viene importato inizialmente nel file di configurazione dell'applicazione si può facilmente sovrascrivere uno qualsiasi dei parametri importati nell'applicazione. Ad esempio, aggiungendo quanto segue al fondo della app / config / config.yml questo andra a sovrascrivere i valori impostati nel bundle.
# app/config/config.yml
parameters:
# Blogger contact email address
blogger_blog.emails.contact_email: assistant@email.com
Questo consente la personalizzazione per il bundle e può fornire impostazioni predefinite per i valori in cui l'applicazione può eseguire l'override.
Nota
osi si ha facilità ai creare parametri di configurazione del bundle usando questo metodo Symfony2 fornisce anche un metodo per esporre una configurazione semantica. Esploreremo questo metodo più avanti nel tutorial.
Creare il modello Email ¶
Il corpo della e-mail è impostato per il rendering di un template. Creare questo template in src / Blogger / BlogBundle / Resources / views / Page / contactEmail.txt.twig e aggiungere quanto segue.
{# src/Blogger/BlogBundle/Resources/views/Page/contactEmail.txt.twig #}
A contact enquiry was made by {{ enquiry.name }} at {{ "now" | date("Y-m-d H:i") }}.
Reply-To: {{ enquiry.email }}
Subject: {{ enquiry.subject }}
Body:
{{ enquiry.body }}
l contenuto dell'e-mail è solo l'insieme dei dati che l'utente ha inviato.
Forse avrete notato anche l'estensione di questo template, è diversa dagli altri template che abbiamo creato. Questa utilizza l'estensione . txt.twig . La prima parte della proroga, . txt specifica il formato del file da generare. I formati più comuni sono :. Txt, html, css,. Js,. Xml e. Json. L'ultima parte dell'estensione specifica quale è il motore di template da utilizzare, in questo caso Twig. Una proroga di . php avrebbe utilizzato PHP per rendere il template..
Ora quando si invia una richiesta, una e-mail verrà inviata all'indirizzo indicato nel parametro blogger_blog.emails.contact_email
.Nota
Symfony2 ci permette di configurare il comportamento della libreria Swift Mailer pur operando in diversi ambienti . Possiamo già vedere questo in uso per l test di ambiente. Per impostazione predefinita, la Distribuzione Symfony2 standard configura Swift Mailer per non inviare messaggi di posta elettronica quando si eseguono i test di ambiente. Questo si vede nel file di configurazione dei test in app / config / config_test.yml .
# app/config/config_test.yml
swiftmailer:
disable_delivery: true
Potrebbe essere utile duplicare questa funzionalità per il dev ambiente. Dopo tutto, non si desidera inviare accidentalmente una e-mail all'indirizzo di posta elettronica sbagliato durante lo sviluppo. Per raggiungere questo obiettivo, aggiungiamo lo stesso codice di cui sopra al file dev di configurazione in app / config / config_dev.yml .
Ci si potrebbe chiedere come è possibile ora verificare che le email vengono inviate, e più precisamente il contenuto di esse, visto che non saranno più consegnate ad un indirizzo di posta elettronica reale. Symfony2 ha una soluzione per questo tramite la barra degli strumenti di sviluppo. Quando un'email è inviata una icona di notifica e-mail apparirà nella barra degli strumenti che contiene tutte le informazioni circa l'e-mail che Swift Mailer avrebbe inoltrato.
Se si esegue un redirect dopo l'invio di una e-mail, come facciamo per il modulo di contatto, è necessario impostare i intercept_redirects impostazione in app / config / config_dev.yml su true per vedere l'email di notifica nella barra degli strumenti.
Avremmo potuto, invece configurare Swift Mailer per inviare tutti i messaggi di posta elettronica a un indirizzo email specifico nel dev ambiente ponendo la seguente impostazione nel file dev di configurazione in app / config / confi
# app/config/config_dev.yml
swiftmailer:
delivery_address: development@symblog.dev
Conclusione ¶
Abbiamo dimostrato i concetti dietro la creazione di una delle parte fondamentale di qualsiasi sito web: il form. Symfony2 viene fornito completo di un ottimo Validator e libreria Form che ci permette di separare la logica di convalida del modulo di modo che possa essere utilizzato da altre parti.Poi sono state introdotte anche alcune impostazioni di configurazione personalizzate che possono essere lette nella nostra applicazione.
Più avanti indrodurremmo Doctrine 2 eil suo uso in Sy2. Andremo a costruire la show page la pagina che mostra il blog e esploreremo il concetto di Data fixtures per inserire dati gia pronti nel database.
