Symfony legjobb gyakorlatai (hivatalos ajánlás)
Webügynökség » Digitális hírek » Symfony legjobb gyakorlatai (hivatalos ajánlás)

Symfony legjobb gyakorlatai (hivatalos ajánlás)

Néhány nappal ezelőtt Fabien Potencie a Sensio-n keresztül bemutatott egy e-könyvet, amely összegyűjti a bevált gyakorlatokat és ajánlásokat egy Symfony projekt fejlesztéséhez. A közösség által közzétett ajánlásokból összeállított dokumentum célja, hogy tanácsokat adjon a telefonnal kapcsolatosaniloSophia a Symfonyból. Ebben a bejegyzésben megpróbálom röviden összefoglalni az angolul leírt 31 tippet.

Bevezetés

Ez a dokumentum néhány tanáccsal és néhány mondattal kezdődik, amelyek célja, hogy inspiráljanak bennünket a dokumentummal.

"Ez a dokumentum nem oktatóanyag"

Ez a dokumentum azzal a szándékkal készült, hogy minden Symfony fejlesztő elolvassa. Szakértők és újoncok egyaránt.

"Ne alakítsa át az alkalmazásait"

A dokumentum elejétől kezdve külön kifejtésre került, hogy ezt az olvasatot követően ne frissítsük és ne alakítsuk át alkalmazásainkat annak érdekében, hogy az tökéletesen illeszkedjen a Sensio számos ajánlásához. Így azonnal kapcsolatba léphetünk a dokumentumban kidolgozott első ötletekkel: ezek a jó gyakorlatok lehetővé teszik számunkra, hogy leegyszerűsítsük életünket, valamint a kód áttekintését. Hozzászólásaim alátámasztására három okot emelek ki:

  • A meglévő alkalmazásai nem tévednek, csak egy másik irányelvet követnek;
  • A teljes kódbázis újrafaktorálása hajlamos hibákat okozni az alkalmazásokban;
  • Az erre fordított munka mennyiségét jobban lehetne a tesztek javítására vagy a végfelhasználók számára valódi értéket biztosító funkciók hozzáadására fordítani.

Hozzon létre egy projektet

A 2. fejezetben, amely egy Symfony projekt deklarálásával és létrehozásával foglalkozik, az első „Legjobb gyakorlat” található:

_Mindig használja a Composert. _A Composer bemutatta a modern PHP alapjait a függőségi felbontáson keresztül. Neki köszönhető, hogy a függőségek regisztráltak az aktában zeneszerző.json feloldásra kerül és visszaküldésre kerül a projektben, hogy használható legyen. Ezen túlmenően, könnyen frissíthetők.

Ily módon tiszteletben tarthatja a Symfony projekt szerkezeti felépítését. (lásd 8. oldal).

Példák:

  • alkalmazás/gyorsítótár tárolja a gyorsítótárat;
  • alkalmazás/naplók üzletnaplók;
  • alkalmazás/források tárolja a sablonokat, valamint az alkalmazás globális fordításait;
  • src / tárolja az alkalmazáscsomagokat;
  • eladó / tárolja a projekt függőségeit;
  • Web/ tárolja az eszközöket (css, js, képek stb.), valamint az elülső fájlt (app.php), amely lehetővé teszi, hogy a kérelmeit később átirányítsa a vezérlőihez.
    Ennek eredményeként új ajánlás a kötegekre vonatkozóan. Saját elemzés nélkül, amely megkérdőjelezheti a philosophie a Symfonytól (amit nem szeretnék), íme az ajánlás:

Hozzon létre egyetlen AppBundle-csomagot egy alkalmazáshoz. Ez a Symfony tervezésének köszönhető. Minden csomagnak _különállónak kell lennie. Ezért képesnek kell lenniük arra, hogy önállóan és függetlenül éljenek.

Hagyom, hogy meditáljon ezen az ajánláson…

Configuration

A harmadik fejezet tanácsokat ad az alkalmazás konfigurálásához. Egyes konfigurációs elemek fejlesztői rendszertől éles rendszerig változhatnak.

Amint az ajánlás is jelzi, ezért meg kell tennie adja meg az infrastruktúrához kapcsolódó konfigurációt az app/config/parameters.yml fájlban.

Ezzel szemben a projektre jellemző konfiguráció, amely statikus lesz, deklarálva lesz app/config/config.yml.

Ezenkívül a fájl paraméterek.yml nem szabad verziószámítani. Ez a fájl paraméterek.yml.dist kinek kellene lennie. Ez a fájl tartalmazza az alkalmazás konfigurálásához szükséges alapvető beállításokat. (ajánlás 12. oldal).

Ennek eredményeként a fájl _app/config/config.yml _maga ajánlásként szolgál.

Állítsa be az alkalmazáshoz kapcsolódó konfigurációt az app/config/config.yml fájlban
Ezt az ajánlást követve azonban célszerű fájlt generálni config.yml, config_dev.yml és egy fájl config_prod.yml. Ezek a fájlok a fejlesztői környezetre és az éles környezetre jellemző állandók tárolására szolgálnak.
Állandónak kell tekintenünk egy értéket, ha az értéke nagyon keveset változik.

Függőség-injekció

Itt vagyunk ! A harmadik fejezetben részletezzük a függőségek használatára vonatkozó ajánlást. Azt tanácsolom, hogy olvassa el ezt az ajánlást, ha magyarázatom homályosnak tűnik.

Ez az ajánlás a szolgáltatások szolgáltatásokba való beillesztésére vonatkozik. Sensio azt javasolja, hogy deklarálja őket egy fájlban src/AppBundle/Resources/config/services.yml.

Arra is felkérem Önt, hogy olvassa el a függőségi injekcióról és a szuperszolgáltatási konténer használatának korlátozásáról szóló cikkemet.

Deklarálja a belső logikát

A 4. fejezet a jelentkezés megszervezésével foglalkozik. Az Ön igényeitől függően a szervezet eltérő lehet. Globális és nem üzleti funkciókhoz a Sensio azt javasolja, hogy helyezze el őket egy mappába utils vagy egyszerűen vegye ki őket a csomagból, és tegye egy külön mappába. Ezt követően erősen ajánlott az osztályát szolgáltatásként nyilvánítani. Egy új ajánlást adunk, amely segít ezek kinyilvánításában.

A szolgáltatás nevének a lehető legrövidebbnek kell lennie, ideális esetben egyetlen szóból.

A fájlformátum kiválasztása

Mivel különösen kötődöm a Yaml formátumhoz a Symfonyon belül, úgy gondolom, hogy ez a pont viszályt fog szítani. A Sensio megalkuvás nélkül a Yaml formátum használatát javasolja az alkalmazásokon belül. A kifejlesztett csomagokat két formátum osztja meg: XML és Yaml.

Sensio úgy döntött, hogy az utóbbit ajánlja, egyszerűen azért, mert ez több " barátságos felhasználói ". Más formátum használata nem változtatja meg az alkalmazás működését.

Ne adjon meg változót a szolgáltatások deklarációjához

Ez egy olyan gyakorlat, amelyet bizonyos csomagokban sokat fog látni, és a Sensio mégis figyelmeztet. Íme a példa, amelyet a szakácskönyv :

1
2
3
4
5
6
7
8
#app/config/services.yml
# szolgáltatás definition osztály névterével paraméterként
paraméterek:
slugger.class: AppBundleUtilsSlugger
szolgáltatások:
slugger:
osztály:
„%slugger.class%”

Itt van egy példa egy haszontalan kódra. Hiba a szolgáltatáshoz használandó osztály deklarálása, mivel ez a változó esetleg máshol is használható a kódban. Ráadásul – és ezt a Sensio is indokolja – ez nehezíti a szolgáltatás létrehozását.

Az ORM választása

A Sensio a Doctrine ORM használatát javasolja a Symfony-n belül. Doctrine felhasználóként a Symfony-ba való integrációja nagyon fejlett. Ez egy olyan ajánlást eredményez, amely újraindítja projektjeink logikus szervezését. Az entitás deklarációjában a logikát egy kötegben kell tartani. Lásd a példát a 18. oldalon.

Nyilatkozat a térképezésről

A Doktrína leképezés deklarálását lehetőleg a Doctrine keretein belül, de más alkalmazásokhoz is ajánlott annotációknak köszönhetően érdemes elvégezni.

Használjon megjegyzéseket az entitásleképezés deklarálásához.
Egy példa a 19. oldalon található.

Armatúrák szerelése

Sensio azt tanácsolja anélkül, hogy előre tenné, állítsa be a lámpatesteket. Az avatatlanok számára ezek olyan adathalmazok, amelyek alapértelmezés szerint az alkalmazás elindítására szolgálnak, még mielőtt élesbe bocsátanák.

Kódolási szabványok (4. fejezet vége)

Ez az a rész, amit Sensio furcsa módon majdnem elhomályosított. – mondom furcsán, mert ez fontos részem.

A Symfony kódolása megfelel a PSR1 és PSR2 szabványoknak. Ezeket a szabványokat népszerűsíteni kell a Symfony fejlesztők közösségében, de a PHP fejlesztők körében is. A Symfony közzétett egy cikket, hogy összegyűjtse és kiemelje a " Kódolási szabványok ". A Sensio vezetője, Fabien Potencie a GitHubon egy olyan eszközt is elhelyezett, amellyel ellenőrizheti a szabványoknak való megfelelést.

Vezérlők

Ha a vezérlőkről van szó, a Symfony philosophie „vékony vezérlők és kövér modellek”. Ez azt jelenti, hogy a vezérlőknek könnyűnek kell maradniuk. Minden olyan metódus (művelet), amelyhez egy útvonalon keresztül hozzáfér, egy műveletet jelent. Mindegyik módszer kódjának "light"-nak kell lennie, és műveleteket kell hívnia és koordinálnia. Ezeknek a részvényeknek a szolgáltatásokban kell lenniük.

Ez a modell a vezérlőt úgy mutatja be, mint amely alkalmazáskódokat/alkatrészeket használ.

A vezérlőnek be kell tartania néhány szabályt

  • Egy vezérlőnek maximum 5 változója lehet.
  • Egy vezérlőnek maximum 10 művelete van.
  • Minden művelet legfeljebb 20 sort tartalmazhat.
    • Egy metódus 20-nál több sort is tartalmazhat, feltéve, hogy a használt kód nem faktorizálható.

      A vezérlőnek örökölnie kell a Sensio FrameworkBundle alapvezérlőjét, és megjegyzésekkel kell kezelnie az útvonalakat, a gyorsítótárat és a biztonságot.

      Annotációk használata javasolt, de érvényes az XML, YAML vagy PHP használata is. Az alkalmazásnak csak egyetlen formátumot szabad használnia.

Ne használja a @sablont

Ez egy ajánlás a kevésbé váratlanoknak, de a magyarázat különösen erőteljes.

Ne használja a @Template() megjegyzést a vezérlő által használt sablon konfigurálásához
A magyarázat egyszerű, a @Template egy TemplateListener-t használ, amelyet az esemény során hívnak meg kernel.view dobják.
A dokumentum elkészítése során tesztet végeztek. A @Template használata 26 ms-ot vesz igénybe a generálás elindítása előtt, míg ugyanezen oldal esetében, amely a " $this->render(…) », a várakozási idő 5 milliszekundum.

Használja a ParamConverter annotációt

Ennek a megjegyzésnek a használata lehetővé teszi egy entitás hidratálásának automatizálását.

A ParamConverter trükk használata akkor jó, ha egyszerű és kényelmes.

sablonok

A 6. fejezet részletezi a sablongenerálást. A _felhajtás _mentes, amit a dokumentum ad nekünk számos ajánlás nyomán.

  • Használja a Twig sablonmotort
    Sensio sok okból ajánlja a Twig-et. Amellett, hogy a motor széles körben használják a PHP közösség, mind a PHP fejlesztők a semmiből, csak a Symfony fejlesztői és más keretrendszerek. Az egyszerűség hangsúlyos, és termékeik reklámozása jól látható. Végül, a Sensio garantálja a Symfony támogatását a 3-as verzióig. Megtalálhatja az első átmeneteket is, amelyeket a 3-as verzióra való átálláshoz szükséges végrehajtani.
  • Tárolja az alkalmazássablonokat alkalmazás/Források/nézetek.
    Alapértelmezés szerint a fejlesztők megszokták, hogy sablonjaikat a mappában tárolják Tudástár minden kötegből. Ez nem rossz dolog, de Fabien Potencie azt javasolja, hogy az alkalmazás globális sablonjait a fent említett mappában tárolja.
  • Határozza meg a Twig bővítményeket AppBundle/Twig és konfigurálja a szolgáltatásokat app/config/services.yml.
    A gallyhosszabbítások rosszul láthatók. Ezeket a kiterjesztéseket, bár nagyon hasznosak is, néha túl szisztematikusan használják. A Sensio ezt az általam elengedhetetlennek tartott részt mutatja be, hogy üzleti kódot illesszen be sablonjaiba. Azt javaslom, hogy olvassa el, hogyan deklarálhat egy Twig kiterjesztést.

Űrlapok

A 7. fejezet utasításokat ad az űrlapok használatára vonatkozóan.

  • Határozza meg űrlapjait a PHP osztályokban.
    A Symfony lehetőséget ad PHP osztályok generálására, amelyek lehetővé teszik az űrlapok automatikus generálását az adott entitásokhoz. A Űrlapok ahogy nevezik, teljes integrációt kínál. Az entitások módosítását segítik. Ezenkívül az Űrlapok használatával lehetővé válik az űrlapok kezelésének deportálása a sablonokból.
  • Ne deklaráljon gombot az űrlap elküldéséhez.
    Ez meglepő szempont, mivel ezt a funkciót a Symfony 2.5-ben vezették be. E sorok írásakor a Symfony 2.6 elfogadása folyamatban van, ezért még nem jelent meg hivatalosan. Ezért feltehetünk néhány kérdést ennek a funkciónak a hasznosságával kapcsolatban, nem szabad használni!Miért adjon hozzá gombokat a sablonokhoz az Űrlapok helyett?
    Magyarázatában a Sensio csapata kifejti, hogy bár ez a funkció megmarad "felhasználóbarát" és hogy leegyszerűsíti az űrlapok megvalósítását, bizonyos funkciók korlátozottak maradnak.
    Például, ha hozzáad egy típusú gombot beküldése "Létrehozás" címkével ez az űrlap nem használható fel szerkesztési oldalon. Ezután az űrlapot szolgáltatásként kell bejelentenie az öröklés végrehajtásához, ami egy kicsit lejjebb nem ajánlott.
  • Ne használjon Twig funkciókat forma() és _formRajt().
    A sablonok megjelenítésével foglalkozó rész felállításra került. Megtanítja nekünk a Twig funkciók használatát forma() és _ form_start()_ elavult. Ez ismét egy hiba számomra, mivel ezek a funkciók csak nemrégiben voltak elérhetőek.
    A Symfonyban többféleképpen is renderelhet egy űrlapot. A különböző renderelési módok közül a legjobb az, amely maximális rugalmasságot kínál.
    A fent felsorolt ​​Twig funkciók használata kevés hasznot hoz. A Sensio a natív HTML-címkék használatakor megnövelt olvashatóságról beszél. Ennek az érvnek ellenére ez egy kis előny... Nagyon kicsi!

Az űrlapokat szolgáltatásként nyilvánítsa

Az űrlapok PHP osztályok, ami azt jelenti, hogy szolgáltatásként deklarálhatók. Ezt a módszert a csomagokban láthatja majd FriendsOfSymfony. Ezt a módszert a Sensio nem ajánlja, kivéve bizonyos esetekben, amelyeket alább idézek:

  • Ha újra szeretné használni a meglévő űrlapokat. A két űrlap közötti öröklődés beállítása lehetővé teszi az összes attribútum átírásának korlátozását.
  • Ha entitásgyűjteményeket akarunk beágyazni.
    Űrlapok szolgáltatásként történő használata űrlap hozzáadása vagy szerkesztése esetén nem javasolt, mert a szolgáltatás használata betölti a @tartály. Ezenkívül nehéz lesz megérteni, hogy ezt a szolgáltatást egy vezérlő használja.

Rögzítse (kötözze) a formáit

A közelmúltban a Sensio megkezdte a Symfony2 kód folyamatos migrálását a jövőbeli Symfony3 kódra. Az elvégezhető módosítások listája között (mind megtalálható az UPGRADE-3.md-ben) található az új megoldás kötőanyag az űrlapon küldött kérést a forma amely létrejött. Az új módszertan részletezése a 21. oldalon található Best Practices.

Hangoztassa a bemutatott kivonatot:

1
2
3
4
5
6
7
8
9
10
11
12
13
nyilvános funkció newAction($request kérés)
{
// építsd fel az űrlapodat
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
$em = $ ezt->container->get(„doctrine.orm.default_entity_manager”);
$em->persist($post);
$em->flush();
visszatérés $ ezt->átirányítás($ ezt->generateUrl("admin_post_show"), sor("azonosító" => $post->getId()));
}
}

Nemzetközivé válás

A nemzetköziesítési modul célja a tartalom lefordítása egyik nyelvről a másikra, a régiótól vagy a felhasználó nyelvétől függően. Ez a fejezet az ajánlási adatokon túl inkább azért készült, hogy bemutassa a lehetőségeket ezen a részen, amely mindig érzékeny marad.

A 8. fejezetben a szerkesztők részletezik, hogyan kell aktiválni a fordítás.

mi a helyzet a formátummal

A Symfony számos fordítási formátumot kínál:

  • PHP
  • Qt
  • .po
  • .mo
  • JSON
  • CSV
  • EZ
  • és sokan mások

    Fordítási fájljaihoz használja az XLIFF formátumot.
    Ez az idézet nyilvánvalóan Sensio ajánlása. Igen, de miért ? Rövid és pontos választ kapunk.
    A támogatott formátumok közül csak az XLIFF formátumot és a gettext formátumot támogatják a professzionális fordítóeszközök. Mivel az XLIFF XML-en alapul, előnyös a tartalomellenőrzés.
    A Symfony 2.6 egy új funkciót kínál, amely lehetővé teszi az XLIFF-fájlok "megjegyzését" (jegyzetek hozzáadását). Ez egy nagy újdonság, mert a fordítási fájlok generálása problémákat okozhat a fordítók számára, hogy megértsék egy mondat jelentését vagy a szövegkörnyezetet, amelyben használják. Röviden, az XLIFF jó!

Hol tároljuk fordítási fájljainkat?

Ez a kérdés bemutatja a Legjobb gyakorlat. A Sensio azt javasolja, hogy tárolja a fájljainkat alkalmazás/Források/fordítások.

Általában minden egyes csomagunkban tároltuk a fordításainkat. Ez nem volt rossz, de a fordításokat általában alkalmazásaink globális részének tekintjük, akárcsak a globális sablonokat, ezért a Sensio azt javasolja, hogy tároljuk őket a app.

Hogyan fordítsuk le alkalmazásainkat?

Mindig használjon kulcsokat a tartalom lefordításához.
Így Legjobb, nem adok véleményt, mivel kevés lehetőségem van pályázatok fordítására. A Sensio azt tanácsolja, hogy egy olyan szó lefordításához, mint a "Felhasználónév", használjon olyan kulcsot, mint pl label.username.

Egy példa a 35. oldalon található.

Biztonság

A könyv 9. fejezete a Symfony központi részére vonatkozik; biztonság !

A Symfony-t arra tervezték, hogy könnyen konfigurálja és hitelesítse azokat a felhasználókat, akik szeretnének csatlakozni alkalmazásainkhoz. Ez a rész nagyon összetett és tele van részletekkel, ezért durva vázlat. További dokumentációt a dedikált oldalon talál.

Deklarálja a tűzfalakat

A konfigurációs beállításokat be kell írni a fájlba biztonság.yml ami benne van app/config.

Hacsak nincs két különböző kapcsolata az alkalmazással (rendszerrel és felhasználókkal), azt javasoljuk, hogy csak egy belépő tűzfalat használjon aktivált névtelen opcióval.
wow wow wow! Várj, megérkezem a Symfonyra, nem értettem semmit!

Mi az a tűzfal?

A Wanadevben található egy cikk a natív hitelesítés deklarálásáról és beállításáról a Symfonyban. Ebben a cikkben részletesen bemutatjuk, mi a tűzfal.

Egyetlen tűzfal? Miért egy ?

Ha most olvasta a fent hivatkozott cikket, akkor észrevehette, hogy több tűzfalat is deklaráltak.

Az adott cikkben a három név volt dev, fő- et Belépés. Ennek ellenére az adott szabályt tiszteletben tartják, csak a tűzfal tekinthető átjárónak.

  • dev : ez a tűzfal lehetővé teszi a debug-bar megjeleníteni.
  • fő- : ez a tűzfal a miénk BELÉPÉSI PONT. A névtelen felhasználók úgy jelentkezhetnek be, mintha betartanák a szabályt. Minden / jellel kezdődő útvonal ezt a bejegyzést fogja használni.
  • Belépés : ez egy tűzfal. Ez lesz az átjárónk egyetlen esetben: ha csatlakozni akarunk. Ez elengedhetetlen a bejelentkezési űrlaphoz való hozzáféréshez.
    A szabályt tehát tiszteletben tartják.

Határozzon meg egy kódolást

A jelszavak kódolása kulcsfontosságú döntés. Többféle algoritmus létezik, mint pl sha (sha1, sha256, sha512, md5...).

A kódolás deklarálásakor (lásd a kódolás deklarálását) három paraméter adható meg.

  • A titkosítási algoritmus (alapértelmezett: sha512);
  • Az iterációk száma (alapértelmezés szerint 5000);
  • A kódolás a kódolt jelszó base64-je (alapértelmezett: igaz).
    Az alapértelmezett értékek ellenére, amelyek módosítására kérem Önt, hogy módosítsa azokat az alkalmazásokhoz. A Sensio az algoritmus használatát is javasolja bcrypt.

    Használjon bcrypt kódolást a felhasználói jelszavak titkosításához.
    Sensio elmagyarázza a bcrypt használatát. Ez magában foglalja a sózás érték. Ez korlátozza a támadásokat, és jobban ellenáll a brute force típusú támadásoknak. További részleteket a fenti Wikipédia cikkben talál.

Állítsa be az engedélyeket

Csatlakozás közben a Symfony érzékeli, hogy melyik tűzfalat kell használni. Ezt követően és még a vezérlőhöz való hozzáférés előtt hozzáférés-ellenőrzés történik. A fájlban vannak meghatározva biztonság.yml,

Sensio a következőket ajánlja:

  1. megvédjük az "él URL-mintáinkat", megértsék globális mintáinkat (például: /admin);
  2. Használj megjegyzéseket @Biztonság amennyire csak lehetséges ;
  3. Ellenőrizze a felhasználó jogait a szolgáltatáson keresztül biztonság.kontextus (a Symfony 2.6 óta a szolgáltatás fejlődött, lásd itt);
  4. A szavazók meghatározása a közúti biztonság egyszerű kezelésére;
  5. Használja a ACL objektum- és felhasználói jogok kezelésére.

Használjon @Biztonsági megjegyzéseket

A Sensio a @Security annotáció használatát javasolja.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
használ SensioCsomagFrameworkExtraBundleConfigurationÚtvonal;
használ SensioCsomagFrameworkExtraBundleConfigurationBiztonság;
//…
/ **
* Megjelenít egy űrlapot egy új bejegyzés entitás létrehozásához.
* @Út("/new", name="admin_post_new")
* @Biztonság("has_role('ROLE_ADMIN')")
*/
nyilvános funkció newAction()
{
//…
}

Használjon kifejezéseket a korlátozások bonyolultabbá tételéhez

Sensio elmagyarázza nekünk, hogy ez az annotáció bonyolultabb feltételek létrehozását is lehetővé teszi, például két objektum két attribútumának összehasonlítását. Ez a megjegyzés szükségessé teheti a ParamConverter.

További információkat a dokumentumban talál:

  • Kifejezések generálása
  • Konvertálja az attribútumokat objektummá

Hozzáférés biztonsága a Twigben

Ha össze szeretné hasonlítani a csatlakoztatott felhasználót egy objektum felhasználójával, elérheti a Twig segítségével használó Folyamatban.

1
2
3
{% if app.user … %}
...
{% endif %}

Kezelje biztonságát egyszerűen

A biztonság kezelése gyakran kényes rész, a kódunk rendszerezése pedig elengedhetetlen része az alkalmazásunk sikeres biztonságának. A ... haszna Választók erősen ajánlott. A kód megszervezésének más módjai is megfontolhatók. Például átvihetünk egy döntést entitásunk metódusába.

A Sensio példát a 40. oldalon tekintheti meg.

Ez a rész nagyon kevéssé részletezett a Symfony által kínált lehetőségekhez képest. Azt tanácsolom, hogy olvasson el egy kicsit több dokumentációt erről a részről, ha biztonsági feladattal szembesül.

Webes eszközök

Az eszközök lehetővé teszik számunkra, hogy kezeljük az olyan erőforrásokat, mint a Javascript, CSS, fos betűtípusok, képek… hogy ezek elérhetők legyenek az Ön oldalairól.

Az eszközöket a weben/ mappában kell tárolni
Így töltheti be erőforrásait a sablonokba, például:

1
2
<link rel="stíluslap" href=« {{ asset(‘css/bootstrap.min.css’) }}«  />
<forgatókönyv src=« {{ asset(‘js/jquery.min.js’) }}« ></forgatókönyv>

Tartsa meg a nyilvános webmappát és mindent, ami benne van.

Használja az Assetic-et

Az Asseticnek több érdeke is van, például a fájlfordítás. Például Less, Sass, TypeScript fájlok… Emiatt a mappa háló nem tartalmazhat fájlokat, például fájlokat .Kevésbé.

Hacsak nem GruntJS-t használ, használja az Asseticet az eszközök összeállításához, kombinálásához és minimalizálásához.

Tudjon meg többet az Asseticről

Az Assetic komplett eszköz, néhány hátránya ellenére. A modul dokumentációját az alábbi linkeken találja:

  • Használja az Assetic-et
  • CSS és JS minimalizálása
  • Tömörítse a képeket
  • Lásd a hivatalos dokumentációt

Állítson be teszteket

A tesztelést a legtöbb fejlesztő alapvetőnek ismeri el. Mégis csak a kisebbség hajtja végre ezeket.

Meglátjuk, hogyan tanácsolja Sensio a tesztek elvégzését.

Végezzen egységteszteket

Az egységtesztek funkcionális tesztek végrehajtására szolgálnak, amelyek viszont tesztelik az alkalmazás logikáját. A Symfony nem határozott meg semmilyen konkrét eszközt a tesztek tesztelésére. Az eszközök PHPUnit et PhpSpec idézik.

Végezzen funkcionális teszteket

Alapvető fontosságú, hogy jó forgatókönyveket készítsenek a funkcionális tesztekhez, de a fejlesztők gyorsan problémákba ütköznek azok végrehajtása során.

Határozzon meg egy funkcionális tesztet annak tesztelésére, hogy az oldal megfelelően betöltődött-e.

Próbáljon meg kódolt URL-eket használni ahelyett, hogy a generátoron keresztül generálja őket.

Tesztelje a JavaScript működését

Sok olyan eszköz létezik, mint pl Nyérc (egy PHPUnit könyvtár) és CasperJS.

Adatkészletek generálása

Ez gyakran aggasztja az adatkészleteket létrehozó fejlesztőket.

A Sensio a könyvtárak használatát javasolja több et Alice.

Következtetés

Ez a cikk innen származik Legjobb gyakorlatok mert symfony. Bár ez a cikk egyszerű marad, az 50 oldalnyi tanácsot kívánja boncolgatni, hogy útmutatást adjon az új Symfony fejlesztőknek.

★ ★ ★ ★ ★