Praktikat më të mira të Symfony (rekomandim zyrtar)

Disa ditë më parë, Fabien Potencier nëpërmjet Sensio, zbuloi një e-libër që bashkon praktikat dhe rekomandimet më të mira për zhvillimin e një projekti Symfony. I përpiluar nga rekomandimet e postuara nga komuniteti, qëllimi i këtij dokumenti është të japë një sërë këshillash në lidhje me philoSophia nga Symfony. Do të përpiqem të përmbledh shkurtimisht 31 këshillat e përshkruara në anglisht në këtë postim.

Prezantimi

Ky dokument fillon me disa këshilla dhe disa fjali që synojnë të na frymëzojnë me dokumentin.

"Ky dokument nuk është një tutorial"

Ky dokument është shkruar me qëllimin që të lexohet nga të gjithë zhvilluesit e Symfony. Edhe ekspertët edhe neofitët.

"Mos i rifaktoroni aplikacionet tuaja"

Që në fillim të dokumentit, shpjegohet në mënyrë specifike se pas këtij leximi, ne nuk duhet të përditësojmë dhe rifaktorojmë aplikacionet tona në mënyrë që ai të përshtatet në mënyrë të përsosur me rekomandimet e shumta të Sensio. Prandaj, ne mund të bëjmë menjëherë lidhjen me idetë e para të zhvilluara në dokument: këto praktika të mira duhet të na lejojnë të thjeshtojmë jetën tonë, si dhe të thjeshtojmë rishikimin e kodit. Për të mbështetur vërejtjet e mia, parashtrohen tre arsye:

• Aplikacionet tuaja ekzistuese nuk janë të gabuara, ato thjesht ndjekin një grup tjetër udhëzimesh;
• Një rifaktorim i plotë i bazës së kodit është i prirur të sjellë gabime në aplikacionet tuaja;
• Sasia e punës së shpenzuar për këtë mund t'i kushtohet më mirë përmirësimit të testeve tuaja ose shtimit të veçorive që ofrojnë vlerë reale për përdoruesit përfundimtarë.

Krijoni një projekt

Në kapitullin 2, i cili trajton mënyrën e deklarimit dhe krijimit të një projekti Symfony, jepet një “Praktika më e mirë” e parë:

_Përdorni gjithmonë Composer. _Composer prezantoi bazat e PHP moderne përmes zgjidhjes së saj të varësisë. Falë tij, varësitë e regjistruara në dosje kompozitor.json do të zgjidhet dhe do të riatdhesohet në projektin tuaj në mënyrë që të jetë i përdorshëm. Përveç kësaj, mund të bëhen përditësime të lehta.

Në këtë mënyrë, ju mund të respektoni organizimin strukturor të një projekti Symfony. (shih faqen 8).

shembuj:

• aplikacion/cache do të ruajë cache;
• aplikacioni/regjistrat shkrimet e dyqaneve;
• aplikacioni/Burimet do të ruajë shabllonet si dhe përkthimet globale për aplikacionin tuaj;
• src / ruani paketat tuaja të aplikimit;
• shitësi / ruani varësitë e projektit tuaj;
• ueb/ do të ruajë asetet (css, js, imazhe, etj.) si dhe skedarin e përparmë (app.php) duke ju lejuar të ridrejtoni më pas kërkesat tuaja te kontrollorët tuaj.
  Si rezultat, një rekomandim i ri për paketat. Pa bërë analizën time e cila mund të vërë në pikëpyetje philosophie nga Symfony (që nuk e dua), ja rekomandimi:

Krijo një paketë të vetme AppBundle për një aplikacion. Kjo është për shkak të mënyrës se si u krijua Symfony. Çdo pako duhet të jetë e pavarur. _Prandaj ata duhet të jenë në gjendje të jetojnë në mënyrë autonome dhe të pavarur.

Ju lë të meditoni mbi këtë rekomandim…

Konfiguracion

Kapitulli i tretë na jep këshilla për të konfiguruar aplikimin e tij. Disa artikuj konfigurimi mund të ndryshojnë nga një sistem zhvillimi në një sistem prodhimi.

Siç tregon rekomandimi, prandaj duhet përcaktoni konfigurimin në lidhje me infrastrukturën tuaj në skedarin app/config/parameters.yml.

Në të kundërt, konfigurimi specifik për projektin tuaj, i cili do të jetë statik, do të deklarohet në app/config/config.yml.

Për më tepër, skedari parametrat.yml nuk duhet të versionohet. Ky është skedari parametrat.yml.dist kush duhet të jetë. Është ky skedar që do t'ju japë opsionet bazë për konfigurimin e aplikacionit tuaj. (rekomandimi faqe 12).

Si rezultat, skedari _app/config/config.yml _vepron si rekomandim.

Vendosni konfigurimin në lidhje me aplikacionin tuaj në app/config/config.yml
Megjithatë, pas këtij rekomandimi, këshillohet të krijoni një skedar config.yml, config_dev.yml dhe një skedar config_prod.yml. Këto skedarë synojnë të ruajnë konstantet specifike për mjedisin e zhvillimit dhe mjedisin e prodhimit.
Ne duhet ta konsiderojmë një vlerë si konstante kur vlera e saj ndryshon shumë pak.

Injeksioni i varësisë

Këtu jemi! Në kapitullin e tretë jepet një rekomandim i detajuar mbi përdorimin e varësive. Ju këshilloj ta lexoni këtë rekomandim nëse shpjegimi im ju duket i paqartë.

Ky rekomandim ka të bëjë me injektimin e shërbimeve në shërbime. Sensio rekomandon deklarimin e tyre në një dosje src/AppBundle/Resources/config/services.yml.

Ju ftoj gjithashtu të lexoni artikullin tim mbi injektimin e varësisë dhe si të kufizoni përdorimin e kontejnerit të super shërbimit.

Deklaroni logjikën e brendshme

Kapitulli 4 mbulon organizimin e aplikimit tuaj. Në varësi të nevojave tuaja, organizata do të ndryshojë. Për funksionet globale dhe jo-biznesore, Sensio rekomandon vendosjen e tyre në një dosje Shërbime ose thjesht hiqni ato nga paketa juaj dhe vendosini në një dosje të veçantë. Pas kësaj, rekomandohet fuqimisht që të deklaroni klasën tuaj si shërbim. Është dhënë një rekomandim i ri për të na ndihmuar në deklarimin e tyre.

Emri i shërbimit tuaj duhet të jetë sa më i shkurtër që të jetë e mundur, në mënyrë ideale një fjalë e vetme.

Zgjedhja e formatit të skedarit

Duke qenë veçanërisht i lidhur me formatin Yaml brenda Symfony, mendoj se kjo pikë do të ngrejë mosmarrëveshje. Sensio rekomandon pa kompromis përdorimin e formatit Yaml brenda aplikacioneve. Paketat e zhvilluara ndahen midis dy formateve: XML dhe Yaml.

Sensio vendosi të rekomandojë këtë të fundit thjesht sepse është më shumë " i lehtë në përdorim ". Përdorimi i një formati tjetër nuk do të ndryshonte mënyrën se si funksionon aplikacioni juaj.

Mos përcaktoni një variabël për deklarimin e shërbimeve tuaja

Kjo është një praktikë që do ta shihni shumë në paketa të caktuara dhe megjithatë Sensio ju paralajmëron. Këtu është shembulli i dhënë në libër gatimi :

1 2 3 4 5 6 7 8

#app/config/services.yml # shërbim definition me hapësirën e emrave të klasës si parametër Parametrat: slugger.class: AppBundleUtilsSlugger shërbimet: slugger: klasa: “%slugger.class%”

Këtu është shembulli i një kodi të padobishëm. Deklarimi i klasës për t'u përdorur për një shërbim është një gabim, pasi kjo variabël mund të përdoret diku tjetër në kod. Përveç kësaj, dhe kjo është arsyeja e dhënë nga Sensio, ajo rëndon krijimin e shërbimit.

Zgjedhja e ORM

Sensio rekomandon përdorimin e Doktrinës ORM brenda Symfony. Duke qenë përdorues i Doktrinës, integrimi i tij në Symfony është shumë i avancuar. Kjo rezulton në një rekomandim që rifillon organizimin logjik të projekteve tona. Deklarata e njësisë ekonomike duhet të mbajë logjikën brenda një pakete. Shihni shembullin në faqen 18.

Deklarata e hartës

Deklarimi i hartës së Doktrinës preferohet të bëhet në sajë të shënimeve që rekomandohen në kuadër të Doktrinës por edhe për aplikime të tjera.

Përdorni shënime për të deklaruar hartën e entitetit.
Një shembull është dhënë në faqen 19.

Instalimi i ndeshjeve

Sensio këshillon pa e vënë përpara, për të vendosur ndeshjet. Për të pa iniciuarit, këto janë grupe të dhënash që do të përdoren si parazgjedhje për të nisur aplikacionin para se ta fusin atë në prodhim.

Standardet e kodimit (fundi i kapitullit 4)

Kjo është një pjesë që Sensio çuditërisht pothuajse e ka eklipsuar. E them çuditërisht pasi është një pjesë e rëndësishme për mua.

Symfony është koduar duke respektuar standardet PSR1 dhe PSR2. Këto standarde duhet të promovohen brenda komunitetit të zhvilluesve të Symfony por edhe me zhvilluesit e PHP. Symfony ka postuar një artikull për të mbledhur dhe theksuar " Standardet e kodimit ". Udhëheqësi i Sensio, Fabien Potencier ka vendosur gjithashtu një mjet në GitHub për të kryer kontrolle mbi përputhjen me standardet.

Kontrolluesit

Kur bëhet fjalë për kontrollorët, ph e Symfonyilosophie “kontrollues të hollë dhe modele të majme”. Kjo do të thotë se kontrollorët duhet të qëndrojnë të lehtë. Çdo metodë (veprim) që do të aksesohet nëpërmjet një rruge paraqet një veprim. Kodi për secilën nga këto metoda duhet të jetë "i lehtë" dhe të thërrasë dhe koordinojë veprimet. Këto aksione duhet të jenë në shërbime.

Ky model paraqet një kontrollues duke përdorur kodet/pjesët e aplikacionit.

Një kontrollues duhet të ndjekë disa rregulla

• Një kontrollues duhet të ketë maksimumi 5 variabla.
• Një kontrollues ka një maksimum prej 10 veprimesh.
• Çdo veprim duhet të përmbajë maksimumi 20 rreshta.
  • Një metodë mund të përmbajë më shumë se 20 rreshta, me kusht që kodi i përdorur nuk mund të faktorizohet.
    

    Një kontrollues duhet të trashëgojë kontrolluesin bazë të FrameworkBundle të Sensio dhe të përdorë shënime për të menaxhuar rrugët, ruajtjen e memories dhe sigurinë.

    Rekomandohet përdorimi i shënimeve, por përdorimi i XML, YAML ose PHP është gjithashtu i vlefshëm. Aplikacioni duhet të përdorë vetëm një format të vetëm.

Mos përdorni @Template

Ky është një rekomandim për më pak të papriturat dhe megjithatë shpjegimi është veçanërisht i fuqishëm.

Mos përdorni shënimin @Template() për të konfiguruar shabllonin e përdorur nga kontrolluesi
Shpjegimi është i thjeshtë, @Template përdor një TemplateListener i cili thirret kur ndodh ngjarja kernel.pamje është hedhur.
Gjatë përgatitjes së këtij dokumenti, u krye një test. Përdorimi i @Template zgjat 26 ms përpara se të nisë gjenerimi ndërsa për të njëjtën faqe që do të ishte krijuar duke përdorur " $this-> render(...) », koha e pritjes prej 5 milisekondash.

Përdorni shënimin e ParamConverter

Përdorimi i këtij shënimi bën të mundur automatizimin e hidratimit të një entiteti.

Përdorimi i trukut ParamConverter është i mirë kur është i thjeshtë dhe i përshtatshëm.

Templates

Kapitulli 6 detajon gjenerimin e shabllonit. Është pa bujë ajo që na jep dokumenti në vazhdën e disa rekomandimeve.

• Përdorni motorin e shabllonit Twig
  Sensio rekomandon Twig për shumë arsye. Përveç të qenit një motor përdoret gjerësisht nga komuniteti PHP, si nga zhvilluesit e PHP nga-zeroja, vetëm nga zhvilluesit e Symfony dhe korniza të tjera. Theksohet thjeshtësia dhe shihet qartë promovimi i produktit të tyre. Më në fund, Sensio garanton mbështetje për Symfony deri në versionin e tij 3. Mund të gjeni gjithashtu kalimet e para që duhet të bëni për të përgatitur kodin tuaj për të migruar në versionin 3.
• Ruani shabllonet e aplikacioneve në aplikacioni/Burimet/shikimet.
  Si parazgjedhje, zhvilluesit janë mësuar të ruajnë shabllonet e tyre në dosje burime të çdo pako. Kjo nuk është një gjë e keqe, por Fabien Potencier rekomandon ruajtjen e modeleve globale për aplikacionin tuaj në dosjen e përmendur më sipër.
• Përcaktoni shtesat tuaja Twig në AppBundle/Twig dhe konfiguroni shërbimet në app/config/services.yml.
  Zgjatjet e degëve vuajnë nga dukshmëria e dobët. Këto zgjerime, sado shumë të dobishme, ndonjëherë përdoren shumë sistematikisht. Sensio prezanton këtë pjesë që më duket thelbësore, si një mënyrë për të injektuar kodin e biznesit në shabllonet e tij. Unë ju rekomandoj të lexoni se si të deklaroni një shtrirje Twig.

Format

Kapitulli 7 na jep udhëzime për përdorimin e formularëve.

• Përcaktoni format tuaja në klasat PHP.
  Symfony jep mundësinë për të gjeneruar klasa PHP duke lejuar gjenerimin e automatizuar të formave për entitetet e dhëna. THE Format siç quhen, ofron integrim të plotë. Ndihmohet modifikimi i subjekteve. Për më tepër, përdorimi i Formave bën të mundur dëbimin e menaxhimit të formularëve nga shabllonet.
• Mos deklaroni një buton për të dërguar formularin e tij.
  Kjo është një pikë befasuese, pasi kjo veçori u prezantua në Symfony 2.5. Në kohën e shkrimit të këtyre rreshtave, Symfony 2.6 është në proces pranimi dhe për këtë arsye nuk është lëshuar ende zyrtarisht. Prandaj, ne mund të ngremë disa pyetje në lidhje me dobinë e këtij funksioni, ai nuk duhet të përdoret!Shtoni butona në shabllone dhe jo në Forma, pse?
  Në shpjegimin e tij, ekipi Sensio shpjegon se edhe pse kjo veçori mbetet "i përshtatshëm për përdoruesit" dhe se thjeshton zbatimin e formularëve, disa funksionalitete mbeten të kufizuara.
  Për shembull, nëse shtoni një buton të llojit paraqesë me një etiketë "Krijo", kjo formë nuk mund të ripërdoret për një faqe redaktimi. Më pas do të duhet të deklaroni formularin tuaj si shërbim për të kryer një trashëgimi, gjë që nuk rekomandohet pak më poshtë.
• Mos përdorni funksionet Twig forma () dhe _formafillimi ().
  Është krijuar një pjesë e dedikuar për paraqitjen e shablloneve. Ajo na mëson se përdorimi i funksioneve Twig forma () Dhe _ forma_fillimi ()_ është zhvlerësuar. Edhe një herë, ky është një gabim për mua pasi këto funksione janë disponuar vetëm kohët e fundit.
  Në Symfony, ka disa mënyra për të dhënë një formë. Nga mënyrat e ndryshme të paraqitjes, mënyra më e mirë është ajo që ofron fleksibilitet maksimal.
  Përdorimi i funksioneve Twig të listuara më sipër sjell pak përfitim. Sensio flet për rritjen e lexueshmërisë kur përdorni etiketat vendase HTML. Pavarësisht këtij argumenti, ky paraqet një përfitim të vogël… Shumë i vogël!

Deklaroni formularët tuaj si shërbime

Formularët janë klasa PHP që do të thotë se ato mund të deklarohen si shërbim. Ju do të mund ta shihni këtë metodë në paketat e FriendsOfSymfony. Kjo metodë nuk rekomandohet nga Sensio përveç në disa raste që citoj më poshtë:

• Nëse dëshironi të ripërdorni formularët ekzistues. Vendosja e trashëgimisë midis dy formave bën të mundur kufizimin e rishkrimit të të gjitha atributeve.
• Nëse duam të vendosim koleksione entitetesh.
  Përdorimi i formularëve si shërbime në rastin e një formulari shtimi ose modifikimi nuk rekomandohet sepse përdorimi i një shërbimi ngarkon @konteiner. Për më tepër, do të jetë e vështirë të kuptohet se ky shërbim përdoret nga një kontrollues.

Ngjit (lidhësin) format e saj

Kohët e fundit, Sensio filloi një migrim të vazhdueshëm të kodit Symfony2 në kodin e ardhshëm Symfony3. Ndër listën e modifikimeve që mund të bëhen (të gjitha i gjeni në UPGRADE-3.md), është zgjidhja e re për kordon kërkesa e dërguar me një formular me formë e cila u krijua. Metodologjia e re është e detajuar në faqen 21 të Praktikat më të mira.

Zëri ekstraktin e paraqitur:

1 2 3 4 5 6 7 8 9 10 11 12 13

publik funksion Veprimi i ri(Kërko $kërkesë) { // ndërtoni formën tuaj $form->handleRequest($kërkesë); if ($form->isSubmitted() && $form->isValid()) { $em = $ kjo-> enë-> merrni("doctrine.orm.default_entity_manager"); $em->persist($post); $em->flush(); kthim $ kjo-> ridrejto($ kjo->generateUrl("admin_post_show"), grup("id" => $post->getId())); } }

Ndërkombëtarizimi

Qëllimi i modulit të ndërkombëtarizimit është përkthimi i përmbajtjes nga një gjuhë në tjetrën, në varësi të rajonit ose gjuhës së përdoruesit. Më shumë se të dhënat e rekomandimeve, ky kapitull është shkruar më shumë për të treguar mundësitë në këtë pjesë e cila mbetet gjithmonë e ndjeshme.

Në kapitullin 8, redaktorët detajojnë se si të aktivizohet përkthim.

po në lidhje me formatin

Symfony ofron një mori formatesh përkthimi:

• PHP
• Qt
• .po
• .mo
• JSON
• CSV
• FILLO
• dhe shume te tjere
  

  Përdorni formatin XLIFF për skedarët tuaj të përkthimit.
  Ky citat është padyshim një rekomandim Sensio. Po por pse? Na jepet një përgjigje e shkurtër dhe e saktë.
  Ndër të gjitha formatet e mbështetura, vetëm formati XLIFF dhe formati gettext mbështeten nga mjete profesionale përkthimi. Meqenëse XLIFF bazohet në XML, ai përfiton nga vërtetimi i përmbajtjes.
  Symfony 2.6 sjell një veçori të re që ju lejon të "komentoni" (shtoni shënime) në skedarët tuaj XLIFF. Kjo është një risi e madhe, sepse krijimi i skedarëve të përkthimit mund të shkaktojë probleme për përkthyesit për të kuptuar kuptimin e një fjalie ose kontekstin në të cilin përdoret. Me pak fjalë, XLIFF është i mirë!

Ku t'i ruajmë skedarët tanë të përkthimit?

Kjo pyetje paraqet një Praktika më e mirë. Sensio rekomandon ruajtjen e skedarëve tanë në aplikacioni/Burimet/përkthimet.

Zakonisht, ne ruanim përkthimet tona në secilën nga paketat tona. Kjo nuk ishte një gjë e keqe, por përkthimet përgjithësisht konsiderohen pjesë globale të aplikacioneve tona, ashtu si shabllonet globale, prandaj Sensio rekomandon që t'i ruajmë në app.

Si të përkthejmë aplikacionet tona?

Përdorni gjithmonë çelësat për të përkthyer përmbajtjen tuaj.
Kështu që Më i mirë, nuk do të jap mendimin tim pasi kam pak mundësi për të përkthyer aplikacione. Sensio këshillon që për të përkthyer një fjalë si "Emri i përdoruesit", duhet të përdorni një çelës si p.sh etiketë.emri i përdoruesit.

Një shembull është dhënë në faqen 35.

Siguria

Kapitulli 9 i librit, ka të bëjë me një pjesë qendrore të Symfony; Siguria !

Symfony është krijuar për të konfiguruar dhe vërtetuar me lehtësi përdoruesit që dëshirojnë të lidhen me aplikacionet tona. Kjo pjesë është shumë komplekse dhe plot detaje, ndaj është një skicë e përafërt. Më shumë dokumentacion mund të gjeni në faqen e dedikuar.

Deklaroni muret tuaja të zjarrit

Opsionet e konfigurimit duhet të futen në skedar siguri.yml e cila është në aplikacioni/konfigurimi.

Nëse nuk keni dy lidhje të ndryshme me aplikacionin tuaj (sistemi dhe përdoruesit), ju rekomandojmë të përdorni vetëm një mur zjarri hyrës me opsionin anonim të aktivizuar.
Ua uaaaa! Prit, arrij në Symfony, nuk kuptova asgjë!

Çfarë është një mur zjarri?

Mund të gjeni një artikull të bërë në Wanadev, se si të deklaroni dhe konfiguroni vërtetimin vendas në Symfony. Në këtë artikull, detajohet se çfarë është një mur zjarri.

Një mur i vetëm i zjarrit? Pse një ?

Nëse sapo keni lexuar artikullin e lidhur më sipër, mund të keni vënë re se disa mure zjarri janë deklaruar.

Në artikullin e dhënë, tre emrat ishin dev, kryesor et hyrje. Pavarësisht kësaj, rregulli i dhënë respektohet, vetëm një mur zjarri mund të konsiderohet si një portë.

• dev : ky firewall lejon debug-bar për të shfaqur.
• kryesor : ky mur zjarri është yni PIKA E HYRJES. Përdoruesit anonimë do të jenë në gjendje të identifikohen sikur të respektojnë rregullin. Të gjitha rrugët që fillojnë me / do të përdorin këtë hyrje.
• hyrje : është një mur zjarri. Kjo do të jetë porta jonë në një rast të vetëm: nëse duam të lidhemi. Kjo është thelbësore për të pasur akses në një formular identifikimi.
  Prandaj, rregulli respektohet.

Përcaktoni një kodim

Kodimi i fjalëkalimeve është një vendim kyç. Ekzistojnë algoritme të shumta, si p.sh sha (sha1, sha256, sha512, md5...).

Kur deklaroni një kodim (shihni si të deklaroni një kodim), mund të jepen tre parametra.

• Algoritmi i enkriptimit (default: sha512);
• Numri i përsëritjeve (si parazgjedhje: 5000);
• Kodimi është base64 i fjalëkalimit të koduar (i parazgjedhur: i vërtetë).
  Pavarësisht këtyre vlerave të paracaktuara, të cilat ju ftoj t'i modifikoni për t'i modifikuar ato për aplikacionet tuaja. Sensio rekomandon gjithashtu përdorimin e algoritmit bcrypt.

  Përdorni kodimin bcrypt për të enkriptuar fjalëkalimet e përdoruesve.
  Sensio shpjegon se si të përdoret bcrypt. Kjo përfshin një kriposja vlerë. Kjo kufizon sulmet dhe është më rezistente ndaj sulmeve të tipit brute-force. Mund të gjeni më shumë detaje në artikullin e mësipërm të Wikipedia.

Vendosni lejet

Gjatë një lidhjeje, Symfony zbulon se cili mur i zjarrit duhet të përdoret. Më pas, dhe madje edhe para hyrjes në kontrollues, kryhet një kontroll aksesi. Ato janë të përcaktuara në dosje siguri.yml,

Sensio rekomandon:

1. mbrojmë "modelet e URL-së së skajshme", kuptoni modelet tona globale (shembull: /admin);
2. Përdorni shënime @Siguria sa më shumë që të jetë e mundur;
3. Kontrolloni të drejtat për një përdorues nëpërmjet shërbimit siguria.konteksti (që nga Symfony 2.6, shërbimi ka evoluar, shih këtu);
4. Përcaktoni votuesit për të menaxhuar me lehtësi sigurinë rrugore;
5. Përdorni ACL për të menaxhuar të drejtat e objektit dhe përdoruesit.

Përdorni shënimet @Security

Sensio rekomandon përdorimin e shënimit @Security.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

përdorim SensioDengFrameworkExtraBundleKonfiguracionRrugë; përdorim SensioDengFrameworkExtraBundleKonfiguracionSiguri; //… / ** * Shfaq një formular për të krijuar një entitet të ri Postimi. * @Rruga(“/i ri”, emri=”admin_post_new”) * @Siguria("has_role('ROLE_ADMIN')") */ publik funksion Veprimi i ri() { //… }

Përdorni shprehje për t'i bërë kufizimet më komplekse

Sensio na shpjegon se ky shënim bën të mundur edhe krijimin e kushteve më komplekse, si për shembull krahasimi i dy atributeve midis dy objekteve. Ky shënim mund të kërkojë përdorimin e ParamConverter.

Mund të gjeni më shumë informacion në dokument:

• Gjeneroni shprehje
• Shndërroni atributet në objekte

Qasuni në sigurinë në Twig

Nëse dëshironi të krahasoni përdoruesin e lidhur me përdoruesin e një objekti, mund të hyni nga Twig the përdorues Në vazhdim

1 2 3

{% if app.user … %} ... {% endif %}

Menaxhoni lehtësisht sigurinë tuaj

Menaxhimi i sigurisë është shpesh një pjesë e ndjeshme dhe organizimi i kodit tonë është një pjesë thelbësore e sigurimit të suksesshëm të aplikacionit tonë. Perdorimi i votuesit rekomandohet shumë. Mund të merren parasysh mënyra të tjera për të organizuar kodin tuaj. Për shembull, ne mund të transferojmë një vendim në një metodë të njësisë sonë.

Shembullin Sensio mund ta shikoni në faqen 40.

Kjo pjesë është shumë pak e detajuar në krahasim me mundësitë që ofron Symfony. Ju këshilloj të lexoni pak më shumë dokumentacion për këtë pjesë nëse keni një detyrë sigurie.

Asetet në ueb

Asetet na lejojnë të menaxhojmë burime të tilla si Javascript, CSS, fos fonts, imazhe… në mënyrë që ato të jenë të aksesueshme nga faqet tuaja.

Asetet tuaja duhet të ruhen në ueb/ dosje
Në këtë mënyrë ju mund të ngarkoni burimet tuaja në shabllonet tuaja si kjo:

1 2	<lidhje rel="Fletë stili" href=« {{ asset(‘css/bootstrap.min.css’) }}«  /> <dorëshkrim src=« {{ asset(‘js/jquery.min.js’) }}« ></dorëshkrim>

Mbani dosjen publike të uebit dhe gjithçka të ruajtur në të.

Përdorni Assetic

Assetic ka interesa të shumta, të tilla si përpilimi i skedarëve. Për shembull, skedarët Less, Sass, TypeScript… Për këtë arsye, dosja web nuk mund të përmbajë skedarë të tillë si skedarë .më pak.

Përdorni Assetic për të përpiluar, kombinuar dhe minimizuar asetet tuaja, përveç nëse përdorni GruntJS.

Mësoni më shumë për Assetic

Assetic është një mjet i plotë, pavarësisht nga disa të meta. Dokumentacionin për këtë modul mund ta gjeni duke përdorur lidhjet e mëposhtme:

• Përdorni Assetic
• Minifiko CSS dhe JS
• Kompreso imazhet
• Shihni dokumentacionin zyrtar

Vendosni teste

Testimi njihet nga shumica e zhvilluesve si thelbësor. Megjithatë, vetëm një pakicë i zbaton ato.

Do të shohim se si Sensio na këshillon të kryejmë testet tona.

Kryeni testet e njësisë

Testet e njësisë përdoren për të kryer teste funksionale që nga ana tjetër do të testojnë logjikën e aplikacionit tuaj. Symfony nuk ka përcaktuar ndonjë mjet të veçantë për të testuar testet tuaja. Mjetet PHPUnit et PhpSpec citohen.

Kryen teste funksionale

Krijimi i skenarëve të mirë për testet tuaja funksionale është thelbësor, dhe megjithatë zhvilluesit hasin shpejt probleme në zbatimin e tyre.

Përcaktoni një test funksional për të provuar nëse faqja juaj është ngarkuar saktë.

Përpiquni të përdorni URL të koduara në vend se t'i gjeneroni ato përmes gjeneratorit.

Testoni funksionalitetin JavaScript

Ekzistojnë shumë mjete si vizon (një bibliotekë PHPUnit) dhe CasperJS.

Gjeneroni grupe të dhënash

Ky është shpesh një shqetësim për zhvilluesit, duke gjeneruar grupe të dhënash.

Sensio rekomandon përdorimin e bibliotekave më shumë et Alice.

Përfundim

Ky artikull është marrë nga Praktikat më të mira për Symfony. Ndërsa mbetet i thjeshtë, ky artikull synon të zbërthejë 50 faqet e këshillave në mënyrë që të udhëzojë zhvilluesit e rinj të Symfony.