Laravel kurz pro začátečníky

Laravel vytvořil Taylor Otwell. Od svého počátečního vydání v červnu 2011 (verze 1) se stal stále populárnějším v sektoru PHP rámců v odvětví vývoje webu. Velkou část této popularity lze přičíst mnoha funkcím zaměřeným na vývojáře, které jsou dodávány se skladem.

Proč Laravel?

Asi 2000, většina PHP kódy byl procedurální a mohl být nalezen ve formě „skriptů“, které by měly zamotanou změť kódu špaget. Ani ty nejjednodušší stránky neměly žádné oddělení obav, a proto bylo docela snadné, aby se aplikace rychle rozrostla v noční můru údržby. Svět potřeboval něco lepšího… Vstupte do PHP verze 5 a různých frameworků PHP, které se pokoušejí přinést tolik potřebné rozlišení a lepší řešení pro různé problémy webových aplikací.

Od té doby jsme viděli mnoho vydaných rámců, které by připravily cestu pro populární rámce existující a používané dnes. Dnes by trojka byla (podle nás) Zend Framework, Symfony a samozřejmě Laravel. Ačkoli každý z těchto rámců byl založen na podobných principech a je zaměřen na řešení (v zásadě) stejných společných problémů, jejich klíčové rozdíly spočívají v jejich implementacích. Každý z nich má své vlastní zvláštnosti, jak postupovat při řešení problémů. Když se podíváte na kód vytvořený každým z nich, uvidíte, že je od sebe odděluje docela plná čára. Podle našeho skromného názoru je Laravel framework nejlepší.

Další informace o Rozdíl mezi Laravel a CodeIgniter

Jak stáhnout a nainstalovat Laravel pomocí Composer

POZNÁMKA Předpokládá se, že již máte na svém lokálním systému nainstalovanou kopii PHP. Pokud ne, můžete si přečíst, jak jej nainstalovat zde

Composer je správce balíčků i závislostí. Chcete-li jej nainstalovat, otevřete terminál a cd do nového adresáře. Spusťte tento příkaz:

curl -Ss getcomposer.org/installer | php

Výsledky tohoto příkazu budou vypadat takto:

Hodnocení Podrobnější pokyny k nastavení Laravelu najdete v dokumentaci k Laravelu zde.

Uvidíte, jak stahuje a kompiluje skript skladatel.phar, který používáme k instalaci Laravelu. Přestože existuje mnoho způsobů, jak nastavit novou aplikaci Laravel, uděláme to pomocí skriptu skladatele Laravel. Chcete-li nainstalovat tento skript, spusťte:

composer global require laravel/installer

Což bude vypadat nějak takto:

Tím se stáhnou a nainstalují všechny samotné soubory frameworku a také všechny závislosti, které to vyžaduje. Balíčky budou uloženy v adresáři dodavatele. Jakmile je stažen a nainstalován, je to stejně snadné jako zadání následujícího příkazu:

laravel new uploadApp

Uvidíte něco jako následující výstup:

Composer instaluje všechny balíčky, které Laravel potřebuje ke spuštění. Může to trvat několik minut, takže buďte trpěliví. Po dokončení spusťte příkaz ls -al a podívejte se, co bylo nainstalováno.

Zde je stručný rozpis adresářů v běžné aplikaci Laravel:

• aplikace/ : Toto je zdrojová složka, kde je uložen kód naší aplikace. Všechny ovladače, zásady a modely jsou v této složce
• bootstrap/: Obsahuje spouštěcí skript aplikace a několik souborů mapy tříd
• config/: Obsahuje konfigurační soubory aplikace. Ty se obvykle neupravují přímo, ale spoléhají se na hodnoty nastavené v souboru .env (environment) v kořenovém adresáři aplikace.
• databáze/: Obsahuje databázové soubory včetně migrací, semen a testovacích továren
• veřejný/: Veřejně přístupná složka obsahující kompilovaná aktiva a samozřejmě soubor index.php
• zdroje/: Obsahuje front-end aktiva, jako jsou soubory javascript, jazykové soubory, soubory CSS/SASS a všechny šablony používané v aplikaci (nazývané šablony blade)
• trasy/: Všechny trasy v aplikaci jsou uvnitř zde. Existuje několik různých „rozsahů“ tras, ale tou, na kterou se zaměříme, je soubor web.php
• úložný prostor/ : Všechny dočasné soubory mezipaměti používané aplikací, soubory relací, skripty kompilovaného zobrazení a soubory protokolu
• testy/: Obsahuje testovací soubory pro aplikaci, jako jsou testy jednotek a funkční testy.
• prodejce/: Všechny balíčky závislostí nainstalované se skladatelem

Nyní tedy sestavme zbytek aplikace a spusťte ji pomocí speciálního řemeslného příkazu (abychom si ušetřili potíže s instalací a konfigurací webového serveru, jako je Apache nebo nginx). Soubor .env obsahuje všechny konfigurační hodnoty, které soubory v adresáři /config používají ke konfiguraci aplikace. Uvnitř si všimnete konfigurační hodnoty pro různé parametry používané vnitřními zařízeními aplikace.

Návrh aplikace: Rychlé shrnutí našich požadavků

V tomto online tutoriálu Laravel vytvoříme velmi jednoduchou aplikaci, která bude dělat pouze dvě věci:

1. zpracovávat nahrávání souborů z webového formuláře
2. zobrazení dříve nahraných souborů na jiné stránce.

Pro tento projekt bude naše aplikace pouze pro zápis, což znamená, že uživatel může zapisovat pouze soubory a prohlížet si seznam souborů, které nahrál. Tato aplikace je extrémně základní, ale měla by vám sloužit jako dobrá praxe, abyste mohli začít budovat své dovednosti a znalosti Laravel. Všimněte si, že v zájmu stručnosti jsem vyloučil jakékoli modelování databází, migrace a ověřování, ale v aplikaci v reálném světě jsou to další věci, které budete chtít zvážit.

Zde je seznam komponent, které budeme potřebovat, aby aplikace fungovala podle očekávání:

• A trasa které umožní vnějšímu světu (internetu) používat aplikaci a také specifikovat koncový bod, který bude ukazovat na místo, kde se nachází logika pro ukládání nahraného souboru
• A kontrolor který zpracovává tok požadavku na odpověď
• A šablona který bude použit k zobrazení seznamu dříve nahraných souborů a samotného formuláře pro nahrání
• A požádat které správce použije k ověření údajů předaných z webového formuláře

Co je to trasa?

Trasa v Laravelu je v podstatě koncový bod určený URI, který funguje jako „ukazatel“ na nějakou část funkčnosti nabízené aplikací. Nejčastěji trasa jednoduše ukazuje na metodu na řadiči a také určuje, které metody HTTP jsou schopny zasáhnout toto URI. Trasa také vždy neznamená metodu kontroléru; mohl by pouze předat spuštění aplikace definované funkci uzavření nebo také anonymní funkci.

Proč používat Route?

Trasy jsou uloženy v souborech ve složce /routes v kořenovém adresáři projektu. Ve výchozím nastavení existuje několik různých souborů odpovídajících různým „stranám“ aplikace („strany“ pochází z metodiky hexagonální architektury). Patří mezi ně:

• web.php Veřejné trasy založené na „prohlížeči“. Tyto jsou nejběžnější a webový prohlížeč je zasáhne. Procházejí skupinou webového middlewaru a obsahují také zařízení pro csrf ochrana (který pomáhá bránit se před škodlivými útoky a hacky založenými na formuláři) a obecně obsahují určitý stupeň „stavu“ (tím myslím, že využívají relace)
• api.php Cesty, které odpovídají skupině API a mají tedy standardně povolený API middleware. Tyto cesty jsou bezstavové a nemají žádné relace ani paměť s křížovými požadavky (jeden požadavek nesdílí data ani paměť s žádným jiným požadavkem – každý je samostatně zapouzdřený).
• console.php Tyto trasy odpovídají vlastním příkazům řemeslníka, které jste vytvořili pro svou aplikaci
• Channels.php Registruje trasy pro vysílání událostí

Klíčovým souborem, který je v tuto chvíli potřeba, je soubor specifický pro prohlížeč, web.php . Ve výchozím nastavení je již definována jedna trasa, což je ta, kterou stisknete přímo při navigaci do webového kořenového adresáře vaší aplikace (webový kořenový adresář je ve veřejném adresáři). Aby naše aplikace pro nahrávání fungovala, budeme potřebovat tři různé cesty:

• /upload Toto bude URI hlavní stránky zobrazující náš webový formulář pro nahrávání souborů.
• /process Zde formulář umístěný na /upload URI odešle svá data odeslaná formulářem ("akce" formuláře)
• /list Zobrazí seznam všech souborů nahraných na web

na vědomí Koncový bod /list nemusí být potřeba, pokud bychom chtěli umístit veškerou logiku pro zobrazení formuláře pro nahrávání a seznamu souborů na jednu stránku, prozatím jsme je však ponechali odděleně, abychom k danému tématu přidali trochu více. .

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download, 'UploadController@download)->name(‘download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

V tomto tutoriálu Laravel framework pro každou požadovanou cestu ji explicitně uvedeme v souboru tras web.php pomocí jedné z dostupných metod požadavku specifických pro HTTP (get(), post(), put() , delete(), patch() nebo options() ). Pro rozpis každého z nich zkontrolujte tento ven. Tyto metody určují, která HTTP slovesa mají povolen přístup k dané trase. Pokud potřebujete, aby trasa mohla přijímat více než jedno HTTP sloveso (což může být případ, kdy používáte jedinou stránku k zobrazení počátečních dat i k odeslání odeslaných dat formuláře), můžete použít Route::any( ) metoda.

Druhý argument pro metodu Route::get() a Route::post() (a kteroukoli z dalších metod souvisejících se slovesy HTTP na fasádě Route) je název konkrétního řadiče a metody umístěné uvnitř řadič, který se spustí po najetí na koncový bod trasy s povoleným HTTP požadavkem (GET, POST, PATCH atd.) Používáme UploadController pro všechny tři trasy a specifikovali jsme je následujícím způsobem:

Poslední metodou, kterou na každé trase voláme, je její funkce name(), která jako argument přijímá jeden řetězec a používá se k víceméně „označení“ konkrétní trasy snadno zapamatovatelným názvem (v našich případech nahrát, zpracovat a vypsat). Uvědomuji si, že se nezdá být tak skvělou funkcí dát každé trase její vlastní název, když je adresa URL pojmenována úplně stejně, ale opravdu se hodí, když máte konkrétní trasu jako /users/profile/dashboard/config, což by bylo snazší zapamatovat si jako profile-admin nebo user-config.

Poznámka k fasádám:

• Fasády poskytují „statické“ rozhraní třídám, které jsou k dispozici v kontejneru služeb aplikace.
• Poskytují stručnou, zapamatovatelnou syntaxi, která vám umožňuje používat funkce Laravelu, aniž byste si pamatovali dlouhé názvy tříd, které je nutné vkládat nebo konfigurovat ručně.

Výše uvedené definice trasy v tomto tutoriálu Laravel frameworku používáme fasádu Route namísto ručního vytváření instance nového objektu Illuminate/Routing/Router a volání odpovídajících metod na tomto objektu. Je to jen zkratka, která šetří psaní. Fasády se hojně používají v rámci Laravel – můžete a měli byste se s nimi blíže seznámit. Dokumenty k Fasádám naleznete zde.

Co je to ovladač?

Řadič je „C“ v architektuře „MVC“ (Model-View-Controller), na které je založen Laravel. Úkol kontrolora lze zredukovat na tuto jednoduchou definici: Přijme požadavek od klienta a vrátí klientovi odpověď. Toto je základní definice a je to také minimální požadavky na daný ovladač. To, co dělá mezi těmito dvěma věcmi, je obecně považováno za „akci“ správce (nebo „implementaci cesty“). Působí jako druhý vstupní bod do aplikace (první je požadavek) ke klientovi, který odešle datovou část požadavku (ke které se dostaneme dále) do aplikace, přičemž očekává nějaký typ odpovědi (ve formě stránka úspěchu, přesměrování, chybová stránka nebo jakýkoli jiný druh odpovědi HTTP).

Ovladač dělá (v podstatě) totéž jako definice trasy s anonymní funkcí nastavenou jako „akce“, když je tato trasa zasažena. Rozdíl je v tom, že řadič dobře odolává oddělení problémů, zatímco trasa je definována inline do skutečné definice adresy URL, což v podstatě znamená, že spojujeme přiřazené URI trasy s implementací trasy nebo kódem, který se spustí, když je tato trasa udeřil.

Například následující dva kusy kódu dosáhnou stejné věci:

Příklad č. 1: Definice a implementace trasy v rámci jediného volání metody (v souboru web.php routes)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
   $name = $request->name;
   return response()->make("<h1>Hello World! This is ".$name, 200);
});

Příklad #2: Definice trasy je uvnitř routes/web.php, ale její implementace je umístěna uvnitř třídy /app/Http/Controllers/HelloWorldController

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
   public function index(Request $request)
   {
       $name = $request->name;
       return response()->make("<h1>Hello World! This is ".$name, 200);
   }
}

I když se příklad Laravelu č. 2 zdá být mnohem pracnější (což není – stačí jen trochu více kódu), podívejte se na výhody, které získáme tím, že naši akční logiku pro danou cestu „hello-world“ vložíme do ovladače. z s definicí trasy jako funkce zpětného volání:

1. Naše logika je čistě rozdělena do své vlastní třídy (oddělení zájmů)
2. Náš ovladač je nastaven pro rozšíření později, pokud bychom k němu potřebovali přidat další funkce... Řekněme, že jsme možná chtěli přidat funkci „sbohem světe“... V tomto případě bychom přejmenovali ovladač na obecnější „HelloController“ a poté definovali dvě samostatné metody, Ahoj() si Ahoj(). Také bychom potřebovali definovat dvě samostatné trasy, které mapovaly /Ahoj si / Ahoj URI na příslušnou metodu na ovladači. To je žádoucí ve srovnání s rozšiřováním souboru tras s implementací každé cesty definovanou jako funkce zpětného volání.
3. Laravel má vestavěnou schopnost ukládat do mezipaměti všechny definice tras v aplikaci, takže urychluje čas potřebný k nalezení dané trasy (zvyšuje výkon aplikace); nicméně, budete to moci využít pouze v případě, že všechny vámi definované trasy v aplikaci jsou nakonfigurovány pomocí mapování specifických pro řadič (viz příklad #2 výše)

Spusťte tento příkaz, který nám vygeneruje nový ovladač.

// ...inside the project's root directory:
php artisan make:controller UploadController   

Tento příkaz v podstatě vygeneruje útržek pro řadič s názvem „UploadController“ v hlavním adresáři řadiče na adrese /app/Http/Controllers/UploadController.php. Neváhejte a otevřete tento soubor a podívejte se. Je to velmi jednoduché, protože se jedná pouze o zakázanou verzi řadiče se správnou cestou jmenného prostoru a požadovanými třídami, ze kterých se rozšiřuje.

Generování požadavku

Než budeme pokračovat v tomto tutoriálu PHP Laravel a provedeme několik změn ve vygenerovaném útržku nástroje UploadController, myslím, že bude smysluplnější nejprve vytvořit třídu požadavku. Je to proto, že metoda řadiče, která zpracovává požadavek, musí ve svém podpisu napsat hint objektu požadavku, což jí umožní automaticky ověřit příchozí data formuláře (jak je specifikováno v metodě rules(). Více o tom později…) Nyní použijme příkaz artisan znovu pro vygenerování útržku našeho požadavku:

php artisan make:request UploadFileRequest

Tento příkaz vygeneruje soubor s názvem UploadFileRequest uvnitř app/Http/Requests/UploadFileRequest. Otevřete útržek a nahlédněte… Zjistíte, že je to velmi jednoduché, obsahuje pouze dvě metody, autorizovat() a pravidla.

Vytvoření ověřovací logiky

Upravme útržek požadavku tak, aby vyhovoval potřebám naší aplikace. Upravte soubor tak, aby vypadal takto:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
   /**
    * Determine if the user is authorized to make this request.
    *
    * @return bool
    */
   public function authorize()
   {
       return true;
   }

   /**
    * Get the validation rules that apply to the request.
    *
    * @return array
    */
   public function rules()
   {
       return [
           'fileName' => 'required|string',
           'userFile' => 'required|file'
       ];
   }
}

Ne mnoho změn, ale všimněte si, že metoda authorize() nyní vrací true namísto false. Tato metoda rozhoduje o tom, zda povolit, aby požadavek vstoupil do aplikace, či nikoli. Pokud je nastavena na hodnotu false, zastaví vstup požadavku do systému (což by normálně byla metoda na ovladači). Bylo by to velmi užitečné místo, kde by bylo možné provádět jakékoli kontroly autorizace na uživatele nebo jakoukoli jinou logiku, která může rozhodnout, zda se požadavek může přesunout dále k řadiči. Prozatím zde vracíme hodnotu true, abychom umožnili všemu a všemu použít požadavek.

Druhá metoda, rules(), je tam, kde veškerá magie vstupuje do hry s ohledem na validaci. Myšlenka je jednoduchá: vrátit pole obsahující sadu pravidel ve tvaru:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Existuje mnoho různých ověřovacích omezení, která jsou podporována Laravelem hned po vybalení. Jejich úplný seznam najdete v online dokumentaci zde. Pro naši aplikaci pro nahrávání budou existovat dvě pole, která budou předána prostřednictvím požadavku POST z formuláře na frontendu. Parametr fileName musí být obsažen v těle formuláře (tj. povinný) a používá se jako název souboru, pod kterým budeme soubor ukládat v úložišti (to se provádí v řadiči – k tomu se dostaneme později). Také určíme, že název souboru musí být řetězec přidáním svislého znaku (|) a slova 'řetězec'. Omezení jsou vždy ohraničena svislými čarami, což umožňuje zadat jakákoli další kritéria pro dané pole na jednom řádku! Jaká síla!

Druhý parametr, userFile , je skutečný soubor, který uživatel nahraje z formuláře na webové stránce. Vyžaduje se také UserFile a musí být souborem. Poznámka: Pokud bychom očekávali, že nahraný soubor bude obrázek, pak bychom místo toho použili omezení obrázku, které by omezilo typy souborů přijaté jako jeden z oblíbených typů obrázků (jpeg, png, bmp, gif nebo svg). Protože chceme uživateli umožnit nahrát jakýkoli typ souboru, budeme se držet omezení ověřování souboru.

To je k objektu požadavku asi vše. Jeho hlavním úkolem je jednoduše dodržet přijatelnou sadu kritérií (omezení), které musí parametry těla formuláře splňovat, aby bylo možné postoupit hlouběji do aplikace. Další věc, kterou je třeba poznamenat, je, že tato dvě pole (userFile a filename) musí být také specifikována uvnitř HTML kódu ve formě vstupních polí (s názvem pole odpovídajícím názvu uvnitř objektu požadavku).

Možná se ptáte: jistě to definuje vlastnosti toho, co by měl požadavek formuláře obsahovat, ale kde se provádí skutečná kontrola těchto omezení? Příště se do toho pustíme.

Úprava ovladače

Otevřete aplikaci/Http/Controllers/UploadController a proveďte v ní následující změny:

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage; 

class UploadController extends Controller
{
   /**
    * This is the method that will simply list all the files uploaded by name and provide a
    * link to each one so they may be downloaded
    *
    * @param $request : A standard form request object
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function list(Request $request)
   {
       $uploads = Storage::allFiles('uploads');

       return view('list', ['files' => $uploads]);
   }

   /**
    * @param $file
    * @return \Symfony\Component\HttpFoundation\BinaryFileResponse
    * @throws BindingResolutionException
    */
   public function download($file)
   {
       return response()->download(storage_path('app/'.$file));
   }

   /**
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function upload()
   {
       return view('upload');
   }

   /**
    * This method will handle the file uploads. Notice that the parameter's typehint
    * is the exact request class we generated in the last step. There is a reason for this!
    *
    * @param $request : The special form request for our upload application
    * @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
    * @throws BindingResolutionException
    */
   public function store(UploadFileRequest $request)
   {
       //At this point, the parameters passed into the $request (from form) are
       //valid--they satisfy each of the conditions inside the rules() method

       $filename = $request->fileName;    //parameters have already been validated
       $file = $request->file('userFile'); //that we don't need any additional isset()

       $extension = $file->getClientOriginalExtension(); //grab the file extension
       $saveAs = $filename . "." . $extension; //filename to save file under

       $file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

       return response()->json(['success' => true]); //return a success message
   }
}

Jde tedy o poměrně přímočarý přístup k ukládání nahraných souborů na disk. Zde je výše uvedený rozpis metody upload():

• Napište nám tip na třídu požadavku v metodě ovladače, která provádí funkci „maso a brambory“, abychom mohli automaticky ověřit příchozí data
• Vytáhněte soubor z (nyní ověřeného) objektu požadavku uvnitř metody kontroleru (v tomto případě jsme jej pojmenovali upload(), ale mohl být také pojmenován standardizovanějším názvem, jako je store()).
• Vyjměte název souboru z požadavku
• Vygenerujte konečný název souboru, který bude použit k uložení souboru. Metoda getClientOriginalExtension() jednoduše vezme původní příponu nahraného souboru.
• Uložte soubor do místního souborového systému pomocí jeho metody storeAs() a předejte pojmenovanou cestu v adresáři /storage jako 1. argument a název souboru, pod kterým se má uložit jako druhý.
• Vraťte odpověď JSON označující, že požadavek byl úspěšný

Šablona čepele

Posledním hlavním kouskem této skládačky je šablona blade, která bude obsahovat veškeré HTML, CSS a javascript pro naši jednoduchou aplikaci. Zde je kód – vysvětlíme jej později.

<body>
   <h1>Upload a file</h1>
   <form id="uploadForm" name="uploadForm" action="{{route('upload')}}" enctype="multipart/form-data">
       @csrf
       <label for="fileName">File Name:</label>
       <input type="text" name="fileName" id="fileName" required /><br />
       <label for="userFile">Select a File</label>
       <input type="file" name="userFile" id="userFile" required />
       <button type="submit" name="submit">Submit</button>
   </form>
   <h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
   <h2 id="error" style="color:red;display:none">Error Submitting File</h2>
   <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   <script>
        $('#uploadForm').on('submit', function(e) {
            e.preventDefault();
            var form = $(this);
            var url = form.attr('action');
            $.ajax({
                url: url,
                type: "POST",
                data: new FormData(this),
                processData: false,
                contentType: false,
                dataType: "JSON",
                success: function(data) {
                    $("#fileName").val("");
                    $("#userFile").val("");
                }
            }).done(function() {
                $('#success').css('display', 'block');
                window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
            }).fail(function() {
                $('#error').css('display', 'block');
                window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
            });
        });
   </script>
</body>
</html>

Tady je to, co je naše /nahrát stránka vypadá takto:

Toto je velmi typický příklad souboru blade obsahujícího formulář HTML a javascript/jQuery pro přidání asynchronní funkčnosti (takže se stránka neobnovuje). Existuje základní tag bez atributu metody (který vysvětlím za sekundu) a se zvláštním atributem akce s hodnotou {{route('file.upload')}}. V blade, to je to, co je známé jako a Směrnice. Direktiva je jen ozdobný název pro funkci – jsou to funkce specifické pro šablony blade, které provádějí různé operace, které jsou společné pro vytváření webových stránek a webových aplikací. Chcete-li lépe porozumět všem skvělým sračkám, které čepel dokáže, podívejte se na dokumenty zde. Ve výše uvedeném případě používáme směrnici pro generování adresy URL pro odeslání formuláře.

Pamatujte, že jsme dříve definovali naše trasy v aplikaci v souboru web.php, přičemž jsme pro každou z nich specifikovali snadno zapamatovatelný název. Direktiva {{route()}} přijímá název trasy, vyhledá jej v seznamu interně uložených tras a vygeneruje úplné URL na základě definice této trasy v souboru web.php. V tomto prvním případě specifikujeme, že chceme, aby formulář odeslal svá odeslaná data na /process URL naší aplikace, která je definována jako POST trasa.

Další podivnou věcí, které jste si mohli všimnout, je značka @csrf přímo pod značkou úvodního formuláře. V blade generuje tato značka parametr _token na formuláři, který se kontroluje uvnitř aplikace předtím, než je povoleno zpracování dat formuláře. Tím je zajištěno, že data ve formuláři jsou platného původu a zabraňuje se útokům typu cross-site-request-forgery. Pro více informací o tomto viz dokumenty.

Poté definujeme náš formulář jako normální, ale nezapomeňte, že názvy našich parametrů formuláře, userFile a fileName jsou přesně stejný jak je definováno uvnitř našeho objektu požadavku. Pokud bychom zapomněli zahrnout vstup pro daný parametr, který byl definován v objektu požadavku (nebo jej napsali chybně), požadavek by selhal a vrátila by se chyba, která by zabránila tomu, aby původní požadavek formuláře vůbec zasáhl metodu ovladače umístěnou na adrese UploadController@ proces .

Pokračujte a vyzkoušejte to a odešlete do aplikace několik souborů pomocí tohoto formuláře. Poté přejděte na /seznam na stránce zobrazíte obsah složky pro nahrání, přičemž soubory, které jste nahráli, jsou uvedeny v tabulce:

Větší obrázek

Vraťme se o krok zpět a podívejme se, co jsme udělali v tomto tutoriálu Laravel.

Tento diagram znázorňuje aplikaci tak, jak je právě teď (vyjma podrobností na vysoké úrovni):

Měli byste si připomenout, že objekt požadavku, který jsme vytvořili na začátku tohoto kurzu Laravel, by měl mít v metodě pravidel definované stejné parametry jako ve formuláři v šabloně blade (pokud ne, přečtěte si znovu část „Vytvoření logiky ověření“). . Uživatel zadá formulář na webové stránce, která je vykreslena pomocí blade šablonového enginu (tento proces je samozřejmě na autopilotu, takže na to nemusíme ani myslet) a formulář odešle. Kód jQuery šablony ve spodní části zastaví výchozí odesílání (které by automaticky přesměrovalo na samostatnou stránku), vytvoří požadavek ajax, načte požadavek s daty formuláře a nahraje soubor a celou věc odešle do první vrstvy našeho aplikace: žádost.

Objekt požadavku se naplní přidružením parametrů uvnitř metody rules() k parametrům odeslaného formuláře a poté ověří data podle každého zadaného pravidla. Pokud jsou všechna pravidla splněna, požadavek se předá jakékoli metodě ovladače, která odpovídá hodnotám definovaným v souboru route web.php. V tomto případě je to metoda process() nástroje UploadController, která dělá práci. Jakmile narazíme na řadič, již víme, že požadavek prošel validací, takže nemusíme znovu testovat, zda je daný název souboru ve skutečnosti řetězec nebo parametr userFile skutečně obsahuje nějaký typ souboru… Můžeme pokračovat jako normální.

Metoda řadiče poté vyjme ověřené parametry z objektu požadavku, vygeneruje úplný název souboru zřetězením předávaného parametru fileName s původní příponou userFile, uloží soubor do adresáře v naší aplikaci a poté vrátí jednoduchý kódovaný JSON odpověď ověřující, že požadavek byl úspěšný. Odpověď je přijata logikou jQuery, která provádí několik dalších úkolů souvisejících s uživatelským rozhraním, jako je zobrazení zprávy o úspěchu (nebo chybě) po dobu 5 sekund, poté ji skryje a také vymaže předchozí položky formuláře… to je proto, aby uživatel věděl pro jistotu, že žádost byla úspěšná a mohou nahrát další soubor, pokud si to přejí.

Všimněte si také na obrázku výše, kde je nakreslena čára mezi klientem a serverem. Tento koncept je naprosto zásadní, abyste pochopili, a pomůže vám vyřešit problémy a problémy, které můžete mít v budoucnu při žonglování, například s více asynchronními požadavky, které se mohou vyskytnout kdykoli. Oddělení je přímo na hranici objektu požadavku. Samotný objekt požadavku lze považovat za „bránu“ ke zbytku aplikace... Provádí počáteční ověření a registraci hodnot formuláře předávaných z webového prohlížeče. Jsou-li považovány za platné, pokračuje k ovladači. Vše před tím je na frontendu („klient“ doslova znamená „na počítači uživatele“). Odpověď je vrácena z aplikace zpět na stranu klienta, kde náš kód jQuery trpělivě naslouchá jejímu příchodu a poté, co ji obdrží, provede několik jednoduchých úloh uživatelského rozhraní.

Pokryli jsme téměř 90+ důležitých často dotazovaných Otázky k pohovoru související s Laravelem a PHP pro nováčky i zkušené kandidáty, aby získali tu správnou práci.