lunedì 21 marzo 2011

Symfony2, struttura di un bundle

Come ho accennato nell'articolo precedente, in Symfony2 i bundle svolgono le funzioni di applicazioni, moduli e plugin di symfony 1.x, quindi le nostre applicazioni saranno organizzate in bundle come lo è del resto il framework stesso.

Chi proviene dalla versione (verrebbe da dire precedente, ma è ancora l'attuale) di Symfony avrà quasi sicuramente letto il tutorial Jobeet. Se ricordate, in tutta la prima parte il codice è organizzato in applicazioni (frontend, backend) e moduli. Poi il giorno 20, vengono presentati i plugin e suggerito un nuovo modo di organizzare il codice trasformando tutto quello che era stato fatto fino a quel momento in un sfJobeetPlugin: un casino di file spostati, classi rinominate e trasformate in astratte. Ricordo che a metà del prendi di qui sposta di là, rinomina questo e quello mi scaricai da SVN il risultato finale della giornata e festa finita, e non credo di essere stato l'unico.

Alla fine ti può convincere l'idea che organizzare anche il proprio codice con i plugin sia la soluzione più pulita e lineare. Però se ti ci fanno arrivare in questo modo, quasi alla fine del tutorial, dopo che magari si è iniziato a fare i primi esperimenti di sviluppo con frontend backend e moduli, è facile continuare ad utilizzare la struttura che si è appresa per prima. Almeno così è successo a me.

Se dovesse esistere qualcosa di simile a Jobeet per Symfony2 non c'è da aspettarsi questo tipo di sorprese. I bundle vengono presentati fino da subito con l'esempio 'Hello world!' e con i bundle si continua.

La struttura elementare di un bundle si capisce anche solo guardando l'organizzazione dei file nel repository di FooAppsHelloBundle anche se vedremo che le cose possono diventare molto più complesse di così.

Controller
  -- DefaultController.php (2)
  -- FriendController.php (2)
Entity
  -- Friend.php (3)
Form
  -- FriendForm.php (4)
Resources
  -- config
  -- -- doctrine
  -- -- -- metadata
  -- -- -- -- orm
  -- -- -- -- -- FooApps.HelloBundle.Entity.Friend.dcm.yml (5)
  -- -- routing.yml (6)
  -- -- validation.yml (7)
  -- doc
  -- -- index.rst (8)
  -- meta
  -- -- LICENSE
  -- views (9)
FooAppsHelloBundle.php (1)

(1) Contiene la dichiarazione della classe del bundle. Il nome del file e della classe devono seguire una precisa convenzione (in realtà ce ne sono più di una, quella seguita nell'esempio è la più comune):

Nome Vendor (FooApps) + nome bundle (Hello) + suffisso Bundle

Se si apre FooAppsHelloBundle.php su GitHub si può notare che la classe si limita ad estendere una classe del framework senza contenere codice specifico ed è dichiarata all'interno di un namespace (FooApps\HelloBundle) anch'esso costruito seguendo una convenzione precisa:

Nome Vendor \ nome bundle + suffisso Bundle

L'esistenza di questa classe e relativo namespace sono il requisito minimo perché si possa registrare un bundle (vedremo prossimamente installazione e registrazione dei bundle). Vero è che un bundle che si limitasse a questo servirebbe a poco, neppure a dire 'Ciao!'.

Accenno brevemente agli altri file perché quasi tutti meritano una trattazione approfondita che sarà fatta nelle prossime puntate.

(2) Controller, il nostro bundle ne usa due. Ogni classe controller ha dei metodi pubblici detti azioni.

(3) Entità, a noi serve solo una entità Friend. Un'istanza di questa classe è un oggetto di cui possiamo ottenere la persistenza nel database tramite l'orm (Doctrine2). La classe è generata a partire dalle informazioni contenute nel file YAML (5). Vedremo che ci sono diversi modi di definire e generare le entità.

(4) Classe del form per la creazione e modifica di un oggetto Friend.

(6) Definizioni delle rotte.

(7) Regole di validazione dell'entità Friend.

(8) Documentazione.

(9) Template. L'esempio utilizza il linguaggio Twig per i template.

Non poco per un "Hello world!" anche se più evoluto rispetto alla versione base. Vedremo tutto un po' per volta.

3 commenti:

Luigi Massa ha detto...

Ciao,
credo si debba aggiungere anche qualche considerazione di base sul pattern utilizzato che poi è alla base di tutto il framework: Dependency Injection

Massimo ha detto...

Sarà fatto, ma in seguito.

Marcello ha detto...

Molto buon articolo, sto solo aspettando di vedere il vostro prossimo.

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.