Symfony-IT » tips

Testare più email contemporaneamente

fullo — Fri, 28 May 2010 09:38:54 +0000

Può capitare di inviare dalla stessa action diverse email, ad esempio per notificare un amministratore di un determinato evento e contemporaneamente per dare feedback all'utente che l'ha scatenato.

In questi casi sfTesterMailer, che con il metodo withMessage(), ci viene incontro dandoci la possibilità di filtrare, filtrando per destinatario, l'email che vogliamo testare.

Supponiamo ad esempio di aver spedito due email, una a admin@example.org e l'altra ad user@example.org in questo ordine.

Il test funzionale corrispondente sarà:

PLAIN TEXT

CODE:

with('mailer')->begin()->
hasSent(2)->
checkHeader('to', '/admin@example.org/')->
withMessage('user@example.org')->
checkHeader('to', '/user@example.org/')->
end();

Inoltre il metodo withMessage() ci permette anche di ciclare all'interno dei messaggi, usando un secondo parametro denominato $position, casomai i messaggi inviati all'utente siano più di uno.

Deselezionare le opzioni di una select multipla in un test funzionale

filippo — Tue, 23 Jun 2009 11:06:50 +0000

Mi è capitato questa mattina di dover fare un test funzionale in cui avevo bisogno di deselezionare una serie di opzioni da una select (all'interno di una form) lasciandone però alcuni selezionati. Guardando sulla documentazione dell'sfTestBrowser ho trovato un metodo per il select e deselect di radiobutton o checkbox. Sfortunatamente non ho trovato un metodo per deselezionare le opzioni di una select senza dover passare un array in post.

Con il mio "pair" mattutino abbiamo quindi deciso di creare un nuovo metodo che sfruttasse il DOM di una pagina html e che potesse rimuovere la selezione di una opzione dato il nome o l'id della select e il valore dell'option.

Abbiamo aperto anche un ticket sul track di Symfony dove potete trovare il nuovo metodo e il test unitario che ne verifica la correttezza!

Buon testing a tutti!!

group by

garakkio — Fri, 13 Mar 2009 14:17:14 +0000

Quante volte vi è capitato di dover fare una semplice group by per contare le righe di una tabella raggruppate per una data colonna? Per intenderci, quello che si fa in maniera semplicissima in SQL con

PLAIN TEXT

CODE:

SELECT type,COUNT(*) AS num FROM card GROUP BY type;

Purtroppo con Propel la cosa non appare subito immediata. Ecco quindi un prezioso metodo da aggiungere alla vostra classe Peer per poterlo fare in modo semplice. Prima di tutto occorre inserire una nuova proprietà $count nel vostro modello (che nel mio esempio si chiama "Card"), con relativi getter e setter:

PLAIN TEXT

CODE:

protected $count;
public function getCount()
{
return $this->count;
}
public function setCount($count)
{
$this->count = $count;
}

Ecco quindi il pezzo forte, in CardPeer (ricordate sempre che va adattato secondo il nome del vostro modello):

PLAIN TEXT

CODE:

/**
* grouped select
* @param Criteria $c
* @param string $column
* @return array
*/
public static function doSelectGroupBy(Criteria $c = null, $column)
{
if (empty($c))
{
$c = new Criteria;
}
self::addSelectColumns($c);
$c->addGroupByColumn($column);
$c->addAsColumn('cnt', 'COUNT(*)');
$stmt = self::doSelectStmt($c);
$cards = array();
while ($row = $stmt->fetch(PDO::FETCH_NUM))
{
$card = new Card;
$col = $card->hydrate($row);
$card->setCount(($row[$col] !== null) ? (int) $row[$col] : null);
$cards[] = $card;
}
return $cards;
}

Ecco infine un esempio di utilizzo:

PLAIN TEXT

CODE:

$cards = CardPeer::doSelectGroupBy(null, CardPeer::TYPE);

personalizzare i filtri nel backend

garakkio — Mon, 23 Feb 2009 14:09:24 +0000

La generazione automatica dei moduli di backend è bellissima, ma a volte c'è da sistemare qualche dettaglio a mano. Un caso esemplare è la form dei filtri, che purtroppo resta in inglese anche se la localizzazione è stata abilitata. Ma con qualche riga aggiuntiva nella classe filter relativa, possiamo metterla facilmente in Italiano (o anche personalizzarla ulteriormente). Innanzitutto occorre individuare la classe giusta: se ad esempio il vostro modello si chiama "BlogPost", dovete modificare il file lib/filter/BlogPostFilter.class.php. Aprite dunque il file, ed inserite queste righe all'interno del metodo configure():

PLAIN TEXT

CODE:

$this->widgetSchema['created_at']->setOption('template', 'da %from_date%
a %to_date%');
$this->widgetSchema['created_at']->getOption('from_date')->setOption('format', '%day%/%month%/%year%');
$this->widgetSchema['created_at']->getOption('from_date')->setOption('empty_values', array('year' => 'anno', 'month' => 'mese', 'day' => 'giorno'));
$this->widgetSchema['created_at']->getOption('to_date')->setOption('format', '%day%/%month%/%year%');
$this->widgetSchema['created_at']->getOption('to_date')->setOption('empty_values', array('year' => 'anno', 'month' => 'mese', 'day' => 'giorno'));

come si può capire facilmente dal codice, non solo abbiamo messo le etichette in Italiano, ma abbiamo anche invertito l'ordine di mese e anno, portandolo nella forma che ci è più consona.
Ovviamente le opzioni viste sopra si possono applicare anche ad un eventuale campo "updated_at", o a qualsiasi altro campo di tipo data.

Sostituire l’helper “input_date_tag()” in Symfony 1.1

fullo — Sun, 27 Jul 2008 17:03:17 +0000

Come molti di voi avranno appreso, a partire da Symfony 1.1 gli helper javascript (e relativi ai form) sono (imho giustamente) da considerarsi deprecati. Questo perchè rendono la scrittura (ma anche l'utilizzo) del codice più complesso del dovuto stravolgendo (e forzando) logiche non sempre corrette.

Tale scelta ha però portato ad alcune mancanze, prima tra tutte l'impossibilità di definire un behavior rich per quelle form più spesso usate, una per tutte quella delle date.

Un'utile soluzione è quindi quella di includere all'interno della propria applicazione UI JQuery e nello special modo il modulo datepicker.

Supponiamo che all'interno della classe che definisce la form del nostro modello esista un widget definito come sfWidgetFormDateTime(). Per sostituire alla scomoda select multipla un calendario javascript dovremmo così agire:

PLAIN TEXT

CODE:

class EventForm extends BaseEventForm
{
public function configure()
{
$this->widgetSchema['date'] = new sfWidgetFormInput();
$this->validatorSchema['date'] = new sfValidatorDateTime( array('with_time' => false) );
}
}

definiamo quindi la vista che mostrerà la nostra form (supponendo di includere nel layout della nostra applicazione jquery.js e ui.js.

PLAIN TEXT

CODE:

et voilà un bellissimo calendario javascript tornerà a rendere "felici" le nostre applicazioni web 2.0

Editare HTML in una textarea

garakkio — Tue, 20 May 2008 14:12:28 +0000

Spesso può servire, specialmente se si sta scrivendo un CMS, utilizzare una textarea per l'editing del codice HTML. Purtroppo Symfony, ad ogni submit di una form, converte il contenuto della textarea stessa trasformando le entità HTML nei rispettivi simboli (c'è anche un ticket aperto a riguardo). Questo fastidioso comportamento fa sì che le pagine HTML create in tal modo non siano più validate, perché tutti i vostri "&" diventeranno inesorabilmente "&".

Per ovviare a questo inconveniente, nell'attesa che il ticket sia chiuso, si può usare questo escamotage. Creare una classe, per esempio /lib/fixAmp.class.php

PLAIN TEXT

CODE:

class fixAmp
{
/**
* fix ampersands in HTML strings
* @param string $txt
* @return string
*/
public static function fixAmps($txt)
{
$txt = mb_eregi_replace('&(?!amp;)', '&', $txt);
$txt = mb_eregi_replace('&#(\d+);', '&#\1;', $txt); // for numeric entities
$txt = mb_eregi_replace('&(\w+);', '&\1;', $txt); // for literal entities
$txt = mb_eregi_replace('&&', '&&', $txt); // for php boolean control
return $txt;
}
}
?>

Quindi nella action basterà applicare il metodo al testo ottenuto dalla textarea.
Ad esempio

PLAIN TEXT

CODE:

$myClass->setContent(fixAmps::fixAmps($this->getRequestParameter('content')));

La classe vista sopra utilizza mb_eregi_replace() per poter funzionare con i caratteri multi-byte, ma si può facilmente modificare per l'utilizzo con preg_replace()

Symfony e Dreamhost

fullo — Mon, 18 Feb 2008 17:03:27 +0000

Utilizzare Symfony dalla shell con Dreamhost spesso porta a ricevere oscuri errori in console come il seguente:

PLAIN TEXT

CODE:

~/dh$ php symfony
Parse error: syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /home/user/domain.com/data/symfony/bin/symfony.php on line 42

il problema dipende dal fatto che la console dell'hosting provider utilizza php4, anche se il vostro dominio funziona con php5.

Per risolverlo la soluzione più semplice è di richiamare staticamente l'interprete di php5 con il seguente percorso

PLAIN TEXT

CODE:

~/dh$ /usr/local/php5/bin/php symfony

alternativamente è possibile crearsi un alias modificando il file .bash_profile del vostro utente aggiungendo la seguente riga:

PLAIN TEXT

CODE:

alias php5='/usr/local/php5/bin/php'

e richiamando quindi symfony usando la più comoda sintassi:

PLAIN TEXT

CODE:

~/dh$ php5 symfony

Svuotare la cache di Symfony da ogni directory del progetto

fullo — Tue, 20 Nov 2007 16:12:28 +0000

Emiliano ci suggerisce un tips utile se usate linux come piattaforma di sviluppo. Si tratta di un piccolo script che permette di svuotare la cache di Symfony da qualsiasi directory di un progetto.

Basta aprire /etc/profile ed inserire al suo interno

PLAIN TEXT

CODE:

alias scc="cd \$(pwd | sed -e \"s#^$/var/www/[^/]\+$.*#\1#\") && symfony cc ; cd -"

a questo punto basterà digitare da console scc e se si è in una sottodirectory di un progetto di symfony magicamente la cache si svuoterà (a patto di avere ovviamente i progetti di Symfony in /var/www)!

eAccelerator e routing dei metodi

fullo — Tue, 04 Sep 2007 10:19:19 +0000

Se utilizzate eAccelerator sul vostro server di produzione e con le ultime due versioni di Symfony ottenete strani messaggi di errore relativi al routing dei metodi simili a

PLAIN TEXT

CODE:

Fatal error:
Uncaught exception 'sfStopException' in /usr/share/pear/symfony/action/sfAction.class.php:136 Stack trace:
#0 /var/www/html/progetto/apps/applicazione/modules/modulo/actions\actions.class.php(19): sfAction->forward('default', 'module')
#1 /usr/share/pear/symfony/action/sfActions.class.php(53): connectActions->executeIndex()
#2 /usr/share/pear/symfony/filter/sfExecutionFilter.class.php(115): sfActions->execute()
#3 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfExecutionFilter->execute(Object(sfFilterChain))
#4 /usr/share/pear/symfony/filter/sfFlashFilter.class.php(50): sfFilterChain->execute()
#5 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfFlashFilter->execute(Object(sfFilterChain))
#6 /usr/share/pear/symfony/filter/sfCommonFilter.class.php(29): sfFilterChain->execute()
#7 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfCommonFilter->execute(Object(sfFilterChain))
#8 /usr/share/pear/symfony/filter/sfWebDeb in /usr/share/pear/symfony/action/sfAction.class.php on line 136

significa che siete incappati in questo scomodo bug.

La soluzione è molto semplice, basta infatti disabilitare il modulo eAccellerator per php o alternativamente limitarsi a bloccarne l'ottimizzazione modificando nel php.ini la direttiva eaccelerator.optimizer = "0" finchè non sarà rilasciata la nuova versione dell'optimizer.

via sfForum

sfGuard e sfSimpleBlog… e le chiavi importate.

giorg — Mon, 27 Aug 2007 12:48:36 +0000

Se stai cercando, su un'installazione fresca di symfony, di far funzionare i due plugin sfGuardPlugin e sfSimpleBlogPlugin ti potrebbe capitare di incorrere nel seguente errore:

[...] Attempt to set foreign key to nonexistent table, sf_guard_user [...]

soprattutto se stai seguendo la documentazione. Ciò è dovuto probabilmente al fatto che nel tuo propel.ini la seconda riga

propel.packageObjectModel

è impostata a false. Mettila a true, e molto probabilmente, facendo il rebuild del modello, incorrerai in:

Execution of target "om-template" failed for the following reason: /usr/share/php5/symfony/lib/vendor/propel-generator/build-propel.xml:470:1: No package found for database "" in generated-schema.xml. The propel.packageObjectModel property requires the package attribute to be set for each database.

A questo punto controlla che il file schema.yml dentro la cartella config/ del tuo progetto sia vuoto: se lo è, cancella il file, e finalmente comincia a lavorare.