Duiken in Symfony 2

Kaders zijn hot topics in de web-industrie en dat is al een tijdje. In deze enorme zee van smaken is Symfony - een uitgebreid PHP-raamwerk dat het immer populaire MVC-paradigma volgt. De leercurve is waarschijnlijk een beetje steiler dan die van zijn concurrenten, zoals CodeIgniter. Maak je geen zorgen, zodra het op je groeit, voel je je sterker dan ooit en kun je fantastische applicaties ontwikkelen.


1. Vereisten

In dit artikel moet je een console-programma gebruiken. Persoonlijk vind ik Git Bash leuk, maar iedereen zal het doen. U moet ook Curl geïnstalleerd hebben om Composer te kunnen installeren.

Als u een Windows-gebruiker bent, kunt u al het bovenstaande gebundeld krijgen door Git voor Windows te installeren, die hier beschikbaar is: Git-downloads.


2. Wat je leert

Tijdens dit artikel kom je meer te weten over:

  • De toepassingsstroom van Symfony
  • Symfony 2.1 installeren met Composer
  • De Symfony-bestandsstructuur en -bundels
  • De console
  • Routes en controllers
  • Antwoorden
  • Takje

3. Een Symfony Lifecycle

Voordat we onze handen vuil en gruizig maken, wil ik een moment gebruiken om de stroom van de Symfony-levenscyclus te verklaren.


De aanvraag

Net als al het andere op het web begint het allemaal met een verzoek. Dit wordt opgepikt door Symfony, die het zal matchen met onze gedefinieerde routes (maak je geen zorgen, dit zal later worden uitgelegd), die vervolgens worden vergeleken met controllers. Dus we vertellen Symfony welke URL's we willen matchen met bepaalde controllers en hun functies.

De Kernel

Dit is waar de magie gebeurt. Symfony zal de URL ontleden en matchen met een van onze routes. Vervolgens wordt de controller geladen die we aan de route hebben toegewezen.

De controller

De controller is geladen en een bepaalde actie wordt uitgevoerd op basis van de route.

Het antwoord

Net als bij een normale HTTP-aanvraag moet een Symfony-verzoek een antwoordobject retourneren.
Het antwoordobject kan op verschillende manieren worden gevormd, bijvoorbeeld met headers.
Een actie moet een geldig antwoordobject retourneren anders wordt er een uitzondering gegenereerd.

Dus nu heb je een korte introductie gehad van de mechanica van Symfony - nu is het tijd om in te duiken.


4. Installatie via Composer

Een van de mooie dingen over webontwikkeling van vandaag, zijn de tools die beschikbaar zijn om uw proces te vergemakkelijken. Een van hen is Composer - een pakketbeheerder voor PHP. Dit artikel bevat geen details over het gebruik van Composer, maar als u geïnteresseerd bent, is dit een geweldige introductie: Eenvoudig pakketbeheer met Composer

Allereerst, als u Composer niet wereldwijd geïnstalleerd hebt, kunt u een lokale installatie downloaden door de volgende opdracht uit te voeren:

 curl -s http://getcomposer.org/installer | php

Test of de installatie werkte door te typen:

 php composer.phar

Als alles goed ging, zou je een menu met beschikbare commando's moeten zien. Als dat niet het geval is, controleert u of u PHP hebt ingesteld in uw omgevingsvariabelen.

Nu gaan we verder met de installatie van Symfony. Vervangen your-folder met welke mapnaam je maar wilt voor je project. U kunt de versie aan het eind ook vervangen door een van uw keuze. Ik raad aan Packagist: Symfony Framework Standard Edition te controleren op de nieuwste stabiele release.

 php composer.phar create-project symphony / framework-standard-edition your-folder / 2.1.4

Je zou nu Composer afhankelijkheden in de map moeten downloaden. Als uw installatie goed is verlopen, gaat u naar your-project.local / web / config.php - hier zal Symfony u vertellen over de serververeisten die ontbreken of optionele uitbreidingen die de prestaties kunnen verbeteren of uw ontwikkeling kunnen vergemakkelijken.

Ga naar als u de vereiste en optionele uitbreidingen hebt ingeschakeld /web/app_dev.php waar je een welkomstscherm met links voor verschillende leerervaringen zou moeten zien. Dit betekent dat Symfony met succes is geïnstalleerd - gefeliciteerd!


5. Inleiding tot de Symfony-bestandsstructuur en -bundels

Op het eerste gezicht lijkt uw hoofdmap misschien een beetje verwarrend. Maak je geen zorgen, er is een logische verklaring achter de structuur. Uw root moet uit deze vier mappen en enkele bestanden bestaan. Je kunt de bestanden negeren, omdat ze op dit moment niet belangrijk zijn.

 app / src / vendor / web /

De app-directory

Hier gaat de configuratie op hoog niveau van uw project. Dit is bijvoorbeeld het huis van de AppKernel klasse die al uw code en bibliotheken van derden in het kader laadt voor uw gebruik.

De app directory bevat ook alle hoofdconfiguratiebestanden, die informatie bevatten over database-login, beveiligingsmodellen, routing en nog veel meer.

Uw HTML-lay-out bevindt zich ook hier.

De Src-gids

De src directory is de thuisbasis van al uw eigen code, die is gegroepeerd in bundels.

Wie of wat is een bundel?

Alle Symfony-code is logisch gegroepeerd in wat bekend staat als bundels. Stel dat uw project een gebruikerssysteem heeft, dan zijn al uw gebruikersgerichte controllers, CSS, JavaScript, database-entiteiten enzovoort opgenomen in een UserBundle. Wat geweldig is aan dit systeem, is dat je een bundel (bijvoorbeeld een gebruikersbeheerbundel) kunt nemen en deze in elk Symfony-project kunt aansluiten.

U kunt zelfs kant-en-klare bundels downloaden van websites zoals KNP-bundels. Tot de populaire keuzes behoren bundels van gebruikerssystemen en CRUD-generatorbundels beheren. Op het moment dat dit artikel werd geschreven, heeft de site 1779 bundels en 4068 ontwikkelaars.

De leveranciersdirectory

Hier zullen alle bibliotheken van derden worden opgeslagen. Dit zit al vol met bibliotheken, bijvoorbeeld Symfony, Doctrine, Assetic en meer.

De webdirectory

Dit moet de hoofdmap van uw domein zijn, omdat dit de enige openbare toegankelijke map van uw project is. Dit is de thuisbasis van uw voorste controllers app.php en app_dev.php bestanden, die de twee openbare toegangspunten voor uw toepassing zijn. Een gebruiker komt uw site binnen via een URL zoals /app.php/products/jeans.

  • app_dev.php is het belangrijkste toegangspunt tijdens het ontwikkelen van uw app. Wanneer u dit gebruikt als uw toegangspunt, zal Symfony caching overslaan en u voorzien van een geweldige ontwikkelingswerkbalk.
  • app.php is het toegangspunt voor de productiemodus. Dit is eigenlijk optioneel gemaakt mod_rewrite, dus de URL's /app.php/products/jeans en / Products / jeans eigenlijk wijzen beide naar dezelfde locatie.

6. Codering met de console ... Wacht, wat?

De console heeft bewezen een briljant hulpmiddel te zijn in mijn ontwikkelingsproces en daarom zeg ik u: u zult niet bang zijn voor uw troost, want u bent de schepper van alle dingen.

Voor mij was een van de (wonderbaarlijk) rare dingen over het overschakelen naar Symfony het zware gebruik van de console.

Laten we er gewoon in duiken. Open uw console en zoek de hoofdmap van het project. Voer deze opdracht in:

 php-app / console

Dit zijn de commando's tot uw beschikking. Meestal gebruik je de generators, cache en asset management. Je zult dit ook gebruiken om bundels te genereren, database schema's te maken, routes te debuggen, cacheverlies en meer.


7. Genoeg praten. Ik wil coderen!

Met wat basiskennis over de structuur en de console, bent u nu klaar om een ​​duik te nemen in Symfony!

Ga naar app_dev.php. Het welkomstscherm dat u hier ziet, is eigenlijk een bundel, zoals die we in een minuut zullen maken. Ga naar src / en verwijder de map toppunt. Als u de pagina vernieuwt, ziet u een fout. Dit komt omdat het AppKernel klasse probeert de bundel te laden die we zojuist hebben verwijderd. Telkens wanneer u een bundel toevoegt of verwijdert, moet u de bundel bewerken AppKernel klasse.

Zo open app / AppKernel.php. Je ziet een array ongeveer als volgt:

 $ bundles = array (nieuwe Symfony \ Bundle \ FrameworkBundle \ FrameworkBundle (), // ... Andere bundels hier);

Hier initialiseert u nieuwe bundels. Als u een bundel via de console maakt, wordt deze automatisch toegevoegd.

Verderop zou je een if-blok als dit moeten zien:

 if (in_array ($ this-> getEnvironment (), array ('dev', 'test'))) $ bundles [] = new Acme \ DemoBundle \ AcmeDemoBundle (); // ... Andere bundels hier

Dit zijn ontwikkelingsbundels, d.w.z. bundels die alleen worden geladen wanneer u zich in de ontwikkelomgeving bevindt (app_dev.php). U zult zien dat dit is waar onze verwijderde bundel is geïnitialiseerd. Verwijder de AcmeDemoBundle regel en sla het bestand op.

Als u vernieuwt, ziet u nu de Symfony-uitzonderingspagina. Dit is waar alle gepakte uitzonderingen u omleiden en meer informatie weergeven. U ziet een uitzondering die ongeveer als volgt luidt:

 Kan resource niet importeren "@ AcmeDemoBundle / Controller / SecuredController.php" ... 

Dit komt omdat Symfony zoekt naar gedefinieerde routes in het controllerbestand SecuredController.php (die zich in de verwijderde AcmeDemoBundle bevond).

Dus wat is een route?

Dit is waarschijnlijk een goed moment om een ​​beetje meer uit te leggen over routes. Kort gezegd is een route een URL-sjabloon. Stel je voor dat je een blog hebt met berichten, in verschillende categorieën. U wilt dus dat de gebruiker in zo'n URL als volgt iets invoert:

 www.myblog.com/categories/Category1 www.myblog.com/categories/Category2 enzovoort 

In Symfony kunt u URL-sjablonen definiëren die u aan een controller koppelt. Stel je het vorige voorbeeld eens voor. Je hebt een functie nodig die de categorienaam heeft gekregen en die naar blogberichten zocht. In een MVC-toepassing, en dus in Symfony, is deze functie verpakt in een controller. Dus het zou er in principe zo uitzien:

 class ControllerExample public function showCategory ($ category_name) // Trek blogposts uit per categorienaam en toon ze

Opmerking: dit is geen geldige Symfony-code, maar slechts een voorbeeld van een eenvoudige blogcontroller.

Nu hoeft u alleen maar de controlleractie en de URL aan elkaar te koppelen. Dit gebeurt via routes. De route in dit geval ziet er als volgt uit:

 / Categorieën / naam

Wanneer een tekenreeks wordt geschreven in accolades, wordt deze geïnterpreteerd als een variabele, die vervolgens wordt doorgegeven aan de gegeven actie. In Symfony kunt u routes definiëren in XML, YML of annotaties. Om het simpel te houden, gebruiken we alleen annotaties in deze tutorial.

U kunt alle gedefinieerde routes bekijken met behulp van de volgende opdracht in de console:

 php app / console-router: debug

Maar vergeet niet dat we een fout hadden. Dit komt omdat Symfony nog steeds op zoek is naar de gedefinieerde routes in onze AcmeDemoBundle controller (die niet bestaat). Dus open app / config / routing_dev.yml en voor nu is alles wat je moet weten dat alle routes worden gedefinieerd of geïmporteerd routing.yml en routing_dev.yml. Verwijder de _demo, _Welkom en _demo_secured sleutels. Als u opfrist, ziet u nu Geen route gevonden voor "GET /". Dit komt omdat er geen routes zijn die overeenkomen met de huidige URL, dus laten we er een maken die dat wel doet.

Maar eerst een controller

Wanneer u routes schrijft als annotaties, schrijft u ze direct boven de actie die u wilt uitvoeren wanneer een gebruiker de opgegeven route invoert. Daarom hebben we nu een bundel nodig die onze controller en actie vasthoudt.

Open uw console en voer de volgende opdracht in:

 php-app / console genereren: bundel

Eerst moet u de naamruimte van uw bundel invoeren. De algemene sjabloon hiervoor is:

 Vendor / BundleName

Leverancier is de auteur van de bundel. Hier kunt u uw bedrijfsnaam of wat u maar wilt typen. Ik gebruik graag mijn initialen EP. Gebruik wat je maar wilt, maar houd het kort.

De naam van de bundel moet eindigen met Bundle. Dus ik zal het volgende invoeren:

 EP / BlogBundle

Vervolgens kunt u de naam kiezen die u wilt gebruiken bij het identificeren van de bundel in uw code.
Ik laat meestal de naam van de leverancier weg, maar druk voor deze zelfstudie op Enter.
Er zijn meer stappen in de generator, maar je zult de standaardwaarden voor deze tutorial willen, dus druk op enter totdat je klaar bent.

Nu open src / YourVendorName / BlogBundle / in je editor. U zult zien dat een basisbundelstructuur voor u is gemaakt. Op dit moment slaan we de details over en gaan we direct naar de controller directory. Open DefaultController.php in controller /.

Dit lijkt veel op het standaardvoorbeeld dat ik eerder heb geschreven, behalve dat de controller een afgeleide is van Controller - een klasse uit het Symfony-frameworkbundel, die de basisfunctionaliteit voor een controller bevat.

Als u naar de actie kijkt, ziet u een aantal annotaties die er als volgt uitzien:

 / ** * @Route ("/ hallo / naam") * @Template () * /

De @Route annotatie vertelt Symfony dat we de route willen matchen / Hallo / naam met de actie \ EP \ BlogBundle \ Controller \ DefaultController :: indexAction () en dat er een variabele is genaamd naam in de URL. Dus als iemand invoert in URL's die lijken op deze:

 www.myblog.com/hello/Esben www.myblog.com/hello/Santa www.myblog.com/hello/Jesus

... ze zullen allemaal naar dezelfde plek gaan, omdat ze allemaal worden gekoppeld aan de / Hallo / naam route.

De @Sjabloon annotatie vertelt Symfony welke View te gebruiken. Wanneer deze leeg wordt gelaten, zal Symfony raden welke weergave moet worden gebruikt op basis van de naam van de controller en de actienaam.

Maar moeten niet alle acties een geldig antwoordobject retourneren?

De oplettende Padawan zal inmiddels gemerkt hebben dat er geen geretourneerd antwoordobject is in deze actie, waarvan ik beweerde dat dit eerder in het artikel was vereist.

Een antwoord is een object dat de code bevat die u wilt weergeven, dienstcodes, headers, enz. Als u bijvoorbeeld een "Hello World" -pagina wilt weergeven, doet u zoiets als dit:

 return new Response ('Hello World!', 200);

Als u een pagina wilt maken voor een AJAX-aanroep, kan dit als volgt worden gedaan:

 return new Response (json_encode (array ('some_variable' => 'enige waarde')), 200, array ('content-type' => 'application / json'));

Als u de gebruiker wilt omleiden, kunt u dit doen met a RedirectResponse voorwerp.

Notitie: U kunt altijd uw antwoord aanpassen aan uw behoeften - statuscodes, headers en meer. Niets is verboden terrein.

Normaal gesproken, als u een weergave wilt weergeven voor de gebruiker, retourneert u een nieuw antwoordobject zoals dit:

 return $ this-> container-> get ('templating') -> renderResponse ('EPBlogBundle: Default: index.html.twig', array ('name' => $ name));

Dit is een lange snelkoppeling die een antwoordobject retourneert met een weergegeven sjabloon als inhoud. Gelukkig heeft de basiscontrollerklasse, waarvan onze controller zich uitstrekt, veel handige snelkoppelingsfuncties. We kunnen het gebruiken render () methode om ons wat tijd te besparen:

 return $ this-> render ('EPBlogBundle: Default: index.html.twig', array ('name' => $ name));

Dit is slechts een kortere weg naar de eerste methode die ik hierboven heb getoond. De eerste parameter is de weergave die moet worden weergegeven. Al onze meningen zitten in onze bundel Resources / views /. De weergaven worden in mappen onderverdeeld op basis van de controller die verantwoordelijk is voor de weergave. Vandaar de naamgevingsconventie Bundel: Controller: View.

De weergave van uw basislay-out (de hoofdsjabloon van uw toepassing) bevindt zich in app / Resources / views /. Aangezien dit niet in een bundel- of controller-map staat, wordt dit eenvoudigweg aangeduid als :: base.html.twig. Een weergave in uw bundel, die is geplaatst in de map met rootbundelweergaven, wordt Bundel :: Weergeven genoemd.

 app / Resources / views / base.html.twig // :: base.html.twig src / BlogBundle / Resources / views / someView.html.twig // EPBlogBundle :: someView.html.twig src / BlogBundle / Resources / views /Default/index.html.twig // EPBlogBundle: standaard: index.html.twig

En ten slotte, de tweede parameter van onze render () functie zijn de variabelen die we voor ons toegankelijk willen maken in onze weergave.

Templating met takje

Twig is een template-engine gebouwd door Sensiolabs - de makers van Symfony. Symfony wordt gebundeld met Twig, hoewel het niet verplicht is om het te gebruiken.

Twig heeft veel leuke functionaliteit die buiten het bestek van dit artikel valt, maar kijk gerust op de officiële Twig-website.

Als je opengaat EPBlogBundle: Standaard: index.html.twig je ziet een code die er als volgt uitziet:

 Hallo name!

Twig gebruikt en %% als start- en eindlabels. Dubbele accolades betekent iets uitvoeren, vergelijkbaar met het PHP-equivalent van . Zo naam betekent om de waarde van onze variabele uit te voeren name $ (wat we Symfony hebben verteld dat we wilden gebruiken toen we ons antwoordobject maakten).

Om je een klein staaltje van Twigs ontzag te geven, zal ik je enkele filters tonen. Een filter is een functie die u op een variabele kunt toepassen. Het wordt toegepast door deze syntaxis te gebruiken var | filter. Hier zijn enkele voorbeelden.

 name | upper // geeft de variabele terug in HOOFDLETTERS name | length // retourneert de lengte van de variabele name | url_encode // retourneert de URL-gecodeerde versie van de variabele

U kunt een volledige lijst met tags, filters en functies bekijken in de officiële Twig-documentatie. Wat Twig echt geweldig maakt, is dat het eigenlijk heel eenvoudig is om je eigen filters en functies te maken. Maar je moet wachten op een andere tutorial voor meer informatie over Twig en de uitbreidbaarheid ervan.


Conclusie

Dit is het einde van onze prachtige reis - en wat een avontuur!

We hebben niet alleen geleerd over de structuur van Symfony en bundels, maar ook over de mogelijkheden van routes en hun controllers. Bestrooi dit met een klein beetje twijg en je bent voorgesteld aan Symfony! Ik kom binnenkort terug met meer diepgaande tutorials over meer specifieke onderwerpen zoals asset management met Assetic en sjablonen met Twig. Bedankt voor het lezen.