Nel libro “The more with symfony” un capitolo viene dedicato a questo plugin come mezzo per sviluppare applicazioni per Facebook oltre che per integrare facilmente Facebook Connect. Io lo sto utilizzando per questo secondo scopo integrandolo su un sito con una base utenti già consolidata ed a cui vorrei dare comunque il vantaggio di accedere con un semplice click o trovarsi loggati nel momento in cui fossero già loggati su Facebook.

Ma vediamo un po’ come funziona il connect e cosa si deve fare perchè tutto fili liscio (parto dal presupposto che seguendo la documentazione si sia modificato lo schema del db per introdurre i nuovi campi necessari al plugin).

Utente non iscritto al sito

Il primo caso è quello di un utente non ancora iscritto al sito che vuole accedervi sfruttando il fatto di essere iscritto a Facebook. Semplicemente cliccando sul pulsante, che avrete posizionato da qualche parte vicino all’area di login, viene richiamata l’azione di signin del plugin che si occupa di recuperare la sessione ed i dati di Facebook per verificare l’eventuale esistenza di un utente già presente a database ed associato al corrente utente Facebook.

Dato che stiamo analizzando il caso dell’utente non iscritto non verrà trovata nessuna corrispondenza, il plugin quindi creerà un nuovo utente sfGuard con username del tipo “Facebook_123456789″ (dove la parte numerica è lo uid di FB per l’utente) e facebook_uid corrispondente all’uid dell’utente. Fatto. Da questo momento l’utente è loggato ed ha una registrazione base al sito dato che spesso nella registrazione “tradizionale” vengono richiesti più dati.

Nel progetto in questione andrò a compilare anche il campo del nickname permettendo così all’utente di utilizzare alcune funzionalità di base, completando invece il proprio profilo avrà l’accesso completo ad altre funzionalità. Così facendo si accontenta sia l’utente (che si iscrive con poco) che il cliente (che vuole sì l’utente ma anche i suoi dati).

Utente già registrato in passato

Il secondo caso è quello dell’utente iscritto al sito tramite la registrazione tradizionale che vuole comunque connettere il proprio account a quello di Facebook per sfruttare l’autenticazione rapida (ed eventuali funzioni di pubblicazione che verranno implementate). Cliccando sul pulsante del connect (da loggato o meno) viene eseguita l’azione di signin che come prima cerca una corrispondenza tra gli utenti presenti; questa volta la trova e invece di creare un nuovo utente modifica quello esistente aggiungendo l’uid dell’utente della sessione Facebook completando così la connessione. Fatto.

Per far funzionare questo ho dovuto aggiornare il metodo invocato per utilizzare il nuovo php-sdk. Il mio fork lo trovate sempre su Github. Ho già richiesto il pull quindi non dovrebbe passare molto tempo prima di vedere tale modifica nel codice “ufficiale” del plugin.

Ok ma il plugin cosa cerca per trovare l’utente corrispondente a quello restituito dalla sessione di Facebook?

Il tassello mancante è rappresentato dal campo email_hash aggiunto, in fase di setup del plugin, al profilo dell’utente. Facebook passa alla nostra applicazione un hash dell’email utilizzata per l’iscrizione (non in chiaro quindi) rappresentata dalla stringa crc32(email)_md5(email) che quindi andrà utilizzata come ricerca sulla tabella degli utenti.

E’ quindi importante fare due cose per disporre di questo hash: per gli utenti già presenti sarà necessario calcolare tale hash e inserirlo nel profilo di ogni singolo utente in modo batch (c’è un task per questo che però al momento non è aggiornato per funzionare con il nuovo php-sdk), per i nuovi iscritti (via registrazione “tradizionale”) andrà calcolato al momento della registrazione andando quindi a modificare il processo utilizzato o invocando un evento che calcola tale hash.

Fatto questo sarà possibile identificare gli utenti tramite l’email_hash evitando così la creazione di utenti duplicati (tradizionale + creato dal plugin).

Fine

Risolto abbastanza velocemente vero? Chiaramente si possono fare molte altre cose: pensate solo ad una versione modificata della registrazione in cui il form viene precompilato partendo dai dati dell’utente recuperati direttamente da Facebook (trovate qualcosa sul capitolo di More with symfony). Se pensate di fare qualche esperimento fate attenzione al fatto che l’applicazione deve essere pubblica (non in lan, raggiungibile da Internet) per permettere a Facebook di comunicare con il plugin.

Il programma delle due giornate è identico mentre a cambiare è l’orario pensato in modo molto intelligente per dare modo a tutti di partecipare anche da diversi fusi orari senza fare le ore piccole. Personalmente ho optato per la seconda giornata per assistere tranquillamente all’evento in orario extra lavorativo senza nessun disturbo, inoltre in caso di imprevisti nella prima giornata sicuramente nella seconda le cose andranno meglio.

Ma di cosa si parlerà?

• Fabien Potencier: Unit & Functional Tests
• François Zaninotto: Symfony 2 Meets Propel 1.5
• Bernhard Schussek: The new form framework
• Fabien Potencier: Miscellaneous enhancements
• Jonathan Wage: What’s new in the Doctrine 2 Symfony Integration
• Fabien Potencier: The Symfony 2 killer feature – you REALLY don’t want to miss this announcement…

Ogni sessione durerà 30 minuti. Ciò che più mi interessa è sicuramente la parte sullo Unit e Functional testing, visto che Symfony 2 passerà da Lime a PHPUnit e farsi un’idea in anticipo non è male. Sarà anche molto interessante vedere all’opera il nuovo form framework.

Che aspettate allora? Correte ad iscrivervi alla conferenza!

Il team italiano dei traduttori (di cui sono fiero di far parte) già da tempo è coinvolto in questo progetto ma non abbiamo potuto anticipare nulla per non rovinare la sorpresa! Buona lettura con la prima puntata!

• inclusione di Propel 1.4
• alcune nuove feature per le migrazioni Doctrine
• cache dei template a cui si accede tramite query string dalla barra degli indirizzi
• migliorie per il metodo ->click() che ora permette l’utilizzo dei selettori CSS

Tutto il resto delle novità che la versione 1.3 di symfony introduce la trovate nel What’s new in symfony 1.3? Disponibile anche nella versione in italiano (grazie Massimiliano per avermelo ricordato). Tra tutte personalmente ritengo molto importanti:

• SwiftMailer 4.1
• sfForm::renderHiddenFields() che ora renderizza i campi hidden degli embedded forms
• sfTesterResponse::checkForm() permette la semplice verifica di tutti i campi di un form

Sul suo blog Potencier ha espresso un po’ di idee sullo stato attuale dell’arte in termini di template engine paragonando ciò che la rete offre, ha anche pubblicato alcuni test comparativi delle performance dei vari prodotti. Risultato: poco meno di 90 commenti in nemmeno una settimana ed un post in risposta da parte di Eli White che solleva alcuni dubbi. Il cerchio si chiude con la risposta di Potencier in un altro post. Consiglio la lettura dei post e di tutti i commenti visto che ci sono degli spunti davvero interessanti su cui non voglio soffermarmi al momento.

Quello di cui vorrei parlare è ad un livello un po’ più alto: template engine si o no?

Personalmente negli ultimi anni ho sviluppato applicazioni con un framework, sviluppato internamente dall’azienda per cui lavoro, basato su Smarty per la creazione dei template. Da quando ho iniziato ad usare symfony, che ricordo è un MVC, mi sono sempre chiesto se mi mancasse davvero Smarty visto che i template si realizzano direttamente in PHP.

La risposta non la so ancora dare, posso tuttavia esprimere dei pareri sulle due strade che si possono seguire:

PHP

• creare i template direttamente in PHP evita di aggiungere un ulteriore layer al tutto
• non si deve imparare un altro linguaggio (per semplice che sia)
• permette più libertà (con attenzione)

TEMPLATE ENGINE

• rende più leggibili i template, specialmente quelli più complessi
• rende più accessibili, in termini di manutenzione, i template anche ai non sviluppatori
• aiuta ad essere più aderenti al design pattern MVC

Quello che più è importante secondo me, che si usi PHP od un template engine, è fare in modo che nella vista (V, di MVC) ci si limiti a presentare i dati e non ad elaborarli. PHP è uno strumento potente più del necessario per “mostrare” dei dati, va usato nel modo giusto. Un template engine dal canto suo, più scarno e povero di funzioni, potrebbe aiutare in tal senso a patto che non lo si vada ad estendere con mille plugin sviluppati ad hoc per tutte le occorrenze. A quel punto tanto vale restare con PHP…

E voi come agite? Quali sono le vostre esperienze in merito?

Swift Mailer 4 sarà incluso in symfony 1.3 come soluzione di default per il mailing, senza dover così ricorrere ad altre soluzioni come Zend_Mail. Personalmente ho già usato Swift Mailer in passato e sto per farlo ancora per dei nuovi progetti.

Se qualcuno fosse interessato a dare il suo contributo può visitare il sito ufficiale e mettersi in contatto con il team di sviluppo.

Ringrazio SensioLabs e tutti gli sponsor che hanno reso possibile un simile evento. Invito voi tutti a partecipare visto che il concorso non è finito e che c’è sempre bisogno di aiuto per fare in modo che il core team sia un po’ meno carico di lavoro a ridosso del rilascio di symfony 1.3.

Ieri è stato molto bello ricevere direttamente da Sensio le due copie in anteprima con i ringraziamenti di Fabien Potencier per il lavoro svolto ed il risultato ottenuto. Dedicare il proprio tempo alla comunità è già qualcosa che ripaga gli sforzi e l’impegno profuso, ricevere un riconoscimento del genere non ha prezzo. Senza dimenticare il fatto di vedere il proprio nome tra i traduttori e una breve descrizione nelle pagine dedicate agli stessi ogni volta che si sfoglia il libro alla ricerca di qualcosa.

Tuttavia i vari sponsor hanno messo a disposizione parecchi regali, ecco cosa mi sono aggiudicato:

• Libro su Doctrine (che dovevo proprio prendere visto il passaggio da Propel a Doctrine che ho deciso)
  
• USB Fan + Light (ficherrimo)
  
• elephpant (ne ho già 2, ma uno vinto vale di più!)
  

L’iniziativa continua quindi proverò anche questo mese a chiudere un ticket al giorno augurandomi di raggiungere il mio obiettivo: essere a Parigi a febbraio! Il problema sarà rappresentato principalmente dal fatto che la connessione mobile con Fastweb non mi permette di utilizzare svn cosa quasi indispensabile per lavorare comodi tra revision e sorgenti vari…