Samouczek Laravela dla początkujących

Co to jest Laravel?

laravel to framework MVC o otwartym kodzie źródłowym dla PHP. Laravel to solidna platforma zapewniająca łatwe tworzenie aplikacji internetowych PHP z funkcjami takimi jak modułowy system pakowania z dedykowanym menedżerem zależności, dostęp do relacyjnych baz danych i inne narzędzia do wdrażania i konserwacji aplikacji.

Laravel został stworzony przez Taylora Otwella. Od premiery w czerwcu 2011 roku (wersja 1) stale zyskuje na popularności w sektorze frameworków PHP w branży tworzenia stron internetowych. W dużej mierze ta popularność wynika z licznych, domyślnie oferowanych funkcji, zorientowanych na programistów.

Dlaczego Laravel?

Większość około 2000 roku kod PHP miał charakter proceduralny i można go było znaleźć w formie „skryptów”, które zawierałyby splątany bałagan w kodzie spaghetti. Nawet najprostsze strony nie miały rozdzielenie obaw, a zatem aplikacja dość łatwo mogła szybko stać się koszmarem w utrzymaniu. Świat potrzebował czegoś lepszego. Pojawiła się wersja PHP 5 i różnorodne frameworki PHP, mające na celu wprowadzenie bardzo potrzebnej struktury i lepszych rozwiązań dla różnych problemów aplikacji internetowych.

Od tego czasu pojawiło się wiele frameworków, które utorowały drogę popularnym frameworkom używanym obecnie. Naszym zdaniem, trzy najlepsze to Zend Framework, Symfony i oczywiście Laravel. Chociaż każdy z tych frameworków opiera się na podobnych założeniach i jest ukierunkowany na rozwiązywanie (zasadniczo) tych samych typowych problemów, ich kluczowe różnice tkwią w implementacji. Każdy z nich ma swoje własne, specyficzne podejście do rozwiązywania problemów. Przyglądając się kodowi generowanemu przez każdy z nich, widać, że istnieje dość wyraźna granica między nimi. Naszym skromnym zdaniem, framework Laravel jest najlepszy.

Dowiedz się więcej o: różnica między Laravel a CodeZapalnik.

Jak pobrać i zainstalować Laravel za pomocą Composera

Uwaga: Ten samouczek został napisany dla Laravela 5.8, ale koncepcje routingu, kontrolera, żądania i Blade pozostają takie same w obecnych wersjach. Od 2026 roku najnowszą wersją jest Laravel 13 (wydana w marcu 2026 roku), która wymaga PHP 8.3 lub nowszego, natomiast Laravel 12 wymaga PHP 8.2.

Uwaga: Zakłada się, że masz już zainstalowaną kopię PHP w swoim systemie lokalnym. Jeśli nie, możesz przeczytać, jak ją zainstalować. w tym miejscu.

Composer jest zarówno menedżerem pakietów, jak i zależności. Aby go zainstalować, otwórz terminal i cd do nowego katalogu. Uruchom to polecenie:

curl -Ss getcomposer.org/installer | php

Wyniki tego polecenia będą wyglądać następująco:

Uwaga: Aby uzyskać bardziej szczegółowe instrukcje dotyczące konfiguracji Laravel, zapoznaj się z dokumentacją Laravel w tym miejscu.

Zobaczysz, jak pobiera i kompiluje skrypt composer.phar, którego używamy do instalacji Laravela. Chociaż istnieje wiele sposobów na skonfigurowanie nowej aplikacji Laravel, my zrobimy to za pomocą skryptu kompozytora Laravela. Aby zainstalować ten skrypt, uruchom:

composer global require laravel/installer

Które będą wyglądać mniej więcej tak:

Spowoduje to pobranie i zainstalowanie wszystkich plików frameworka oraz wszystkich wymaganych przez niego zależności. Pakiety zostaną zapisane w katalogu dostawcy. Po pobraniu i zainstalowaniu wystarczy wydać następujące polecenie:

laravel new uploadApp

Zobaczysz coś takiego:

Composer instaluje wszystkie pakiety potrzebne Laravelowi do uruchomienia. Może to potrwać kilka minut, więc bądź cierpliwy. Po zakończeniu uruchom polecenie ls -al, aby sprawdzić, co zostało zainstalowane.

Oto krótki opis katalogów w popularnej aplikacji Laravel:

• aplikacja/ : To jest folder źródłowy, w którym znajduje się kod naszej aplikacji. Wszystkie kontrolery, zasady i modele znajdują się w tym folderze.
• bootstrap/ : Zawiera skrypt startowy aplikacji i kilka plików mapy klas.
• konfiguracja/ : Przechowuje pliki konfiguracyjne aplikacji. Zazwyczaj nie są one modyfikowane bezpośrednio, lecz opierają się na wartościach skonfigurowanych w pliku .env (środowiskowym) w katalogu głównym aplikacji.
• Baza danych/ : Przechowuje pliki bazy danych, w tym migracje, nasiona i fabryki testowe.
• publiczny/ : Publicznie dostępny folder zawierający skompilowane zasoby i oczywiście plik index.php.
• zasoby/ : Zawiera zasoby front-end, takie jak: JavaPliki skryptów, pliki językowe, pliki CSS/SASS i wszystkie szablony używane w aplikacji (nazywane szablonami blade).
• trasy/ : Wszystkie trasy w aplikacji znajdują się tutaj. Istnieje kilka różnych „zakresów” tras, ale skupimy się na pliku web.php.
• składowanie/ : Wszystkie tymczasowe pliki pamięci podręcznej używane przez aplikację, pliki sesji, skompilowane skrypty widoków i pliki dziennika.
• testy/ : Zawiera pliki testowe aplikacji, takie jak testy jednostkowe i testy funkcjonalne.
• sprzedawca/ : Wszystkie pakiety zależności zainstalowano za pomocą kompozytora.

Teraz zbudujmy resztę aplikacji i uruchommy ją za pomocą specjalnego polecenia Artisan (aby oszczędzić sobie kłopotu z instalacją i konfiguracją serwera WWW, takiego jak Apache czy nginx). Plik .env zawiera wszystkie wartości konfiguracyjne używane przez pliki w katalogu /config do konfiguracji aplikacji.

Projekt aplikacji: Krótkie podsumowanie naszych wymagań

W tym internetowym samouczku Laravel będziemy budować bardzo prostą aplikację, która zrobi tylko dwie rzeczy:

1. obsługiwać przesyłanie plików z formularza internetowego
2. wyświetlić wcześniej przesłane pliki na innej stronie.

W tym projekcie nasza aplikacja będzie działać tylko w trybie zapisu, co oznacza, że ​​użytkownik będzie mógł jedynie zapisywać pliki i przeglądać listę przesłanych przez siebie plików. Ta aplikacja jest niezwykle prosta, ale powinna posłużyć jako dobry trening, abyś mógł rozpocząć rozwijanie umiejętności i wiedzy z zakresu Laravel. Pamiętaj, że dla zwięzłości pominęliśmy modelowanie baz danych, migracje i uwierzytelnianie, ale w rzeczywistej aplikacji są to dodatkowe elementy, które warto wziąć pod uwagę.

Oto lista komponentów, które będą nam potrzebne, aby aplikacja działała zgodnie z oczekiwaniami:

• A trasa co umożliwi światu zewnętrznemu (Internetowi) korzystanie z aplikacji, a także określi punkt końcowy, który będzie wskazywał miejsce, w którym znajduje się logika zapisywania przesłanego pliku.
• A kontroler który obsługuje przepływ żądania do odpowiedzi.
• A szablon który będzie używany do wyświetlania listy wcześniej przesłanych plików i samego formularza przesyłania.
• A zażądać którego kontroler będzie używał do weryfikacji danych przekazywanych za pośrednictwem formularza internetowego.

Co to jest trasa?

Trasa w Laravel to w zasadzie punkt końcowy określony przez URI, który działa jako „wskaźnik” do pewnej funkcjonalności oferowanej przez aplikację. Najczęściej trasa po prostu wskazuje na metodę kontrolera i określa, które metody HTTP mogą dotrzeć do tego URI. Trasa nie zawsze oznacza metodę kontrolera; może również po prostu przekazać wykonanie aplikacji do zdefiniowanego obiektu Closure lub funkcji anonimowej.

Dlaczego warto używać trasy?

Trasy są przechowywane w plikach w folderze /routes w katalogu głównym projektu. Domyślnie istnieje kilka różnych plików odpowiadających różnym „stronom” aplikacji („strony” pochodzą z metodologii architektury heksagonalnej). Obejmują one:

• web.php: publiczne ścieżki oparte na „przeglądarce”. Są one najczęstsze i to właśnie one trafiają do przeglądarki internetowej. Działają one poprzez grupę oprogramowania pośredniczącego i zawierają również narzędzia do… Ochrona CSRF (co pomaga w obronie przed złośliwymi atakami opartymi na formularzach) i na ogół zawierają pewien stopień „stanu” (przez co rozumiemy, że wykorzystują sesje).
• api.php: trasy odpowiadające grupie API, a zatem z domyślnie włączonym oprogramowaniem pośredniczącym API. Trasy te są bezstanowe i nie posiadają sesji ani pamięci między żądaniami (jedno żądanie nie współdzieli danych ani pamięci z żadnym innym żądaniem; każde jest samoenkapsulowane).
• console.php: te trasy odpowiadają niestandardowym poleceniom Artisan, które utworzyłeś dla swojej aplikacji.
• channels.php: rejestruje trasy do transmisji zdarzeń.

Kluczowym plikiem, którym należy się teraz zająć, jest plik web.php, specyficzny dla danej przeglądarki. Jedna ścieżka jest już zdefiniowana domyślnie, czyli ta, którą klikasz po przejściu do katalogu głównego aplikacji (katalog główny znajduje się w katalogu publicznym). Aby nasza aplikacja do przesyłania danych działała, będziemy potrzebować trzech różnych ścieżek:

• /upload: będzie to adres URI strony głównej, na której wyświetlany jest nasz formularz internetowy umożliwiający przesyłanie plików.
• /process: w tym miejscu formularz znajdujący się pod adresem URI /upload będzie publikował dane przesłane przez formularz („akcja” formularza).
• /list: wyświetla listę wszystkich plików przesłanych na stronę.

Uwaga: punkt końcowy /list może nie być potrzebny, jeśli chcemy umieścić całą logikę wyświetlania formularza przesyłania i listy plików na jednej stronie; na razie jednak zachowaliśmy je osobno, aby dodać nieco więcej treści do omawianego tematu.

//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');

W tym samouczku dotyczącym frameworka Laravel, dla każdej żądanej trasy, będziemy ją jawnie wymieniać w pliku routes.php, używając jednej z dostępnych metod żądania specyficznych dla protokołu HTTP (get(), post(), put(), delete(), patch() lub options()). Aby uzyskać szczegółowe informacje na temat każdej z nich, sprawdź to out. Metody te określają, które polecenia HTTP mogą uzyskiwać dostęp do danej trasy. Jeśli trasa musi akceptować więcej niż jedno polecenie HTTP (co może mieć miejsce, gdy używasz jednej strony do wyświetlania danych początkowych i danych po przesłaniu formularza), możesz użyć metody Route::any().

Drugim argumentem metod Route::get() i Route::post() (oraz wszystkich innych metod powiązanych z czasownikami HTTP w fasadzie Route) jest nazwa konkretnego kontrolera oraz metoda w nim zawarta, która jest wykonywana po dotarciu do punktu końcowego trasy z dozwolonym żądaniem HTTP (GET, POST, PATCH itd.). Używamy kontrolera UploadController dla wszystkich tras i określiliśmy je w następujący sposób:

Ostatnią metodą, którą wywołujemy dla każdej trasy, jest jej funkcja name(), która przyjmuje pojedynczy ciąg znaków jako argument i służy do mniej lub bardziej „oznaczania” konkretnej trasy łatwą do zapamiętania nazwą (w naszych przypadkach: upload, process i list). Nadanie każdej trasie własnej nazwy może nie wydawać się zbyt kuszącą funkcją, gdy URL ma dokładnie taką samą nazwę, ale jest naprawdę przydatna, gdy masz konkretną ścieżkę, np. /users/profile/dashboard/config, którą łatwiej zapamiętać jako profile-admin lub user-config.

Uwaga na temat fasad:

• Fasady zapewniają „statyczny” interfejs do klas dostępnych w kontenerze usług aplikacji.
• Zapewniają zwięzłą, zapadającą w pamięć składnię, która pozwala korzystać z funkcji Laravela bez zapamiętywania długich nazw klas, które należy wprowadzić lub skonfigurować ręcznie.

W powyższych definicjach tras używamy fasady Route zamiast ręcznego tworzenia nowego obiektu Illuminate/Routing/Router i wywoływania odpowiednich metod na tym obiekcie. To po prostu skrót, który oszczędza czas.pingFasady są szeroko wykorzystywane w całym frameworku Laravel; możesz i powinieneś bliżej się z nimi zapoznać. Dokumentację dotyczącą fasad można znaleźć tutaj w tym miejscu.

Co to jest kontroler?

Kontroler to „C” w architekturze „MVC” (Model-View-Controller), na której opiera się Laravel. Zadanie kontrolera można sprowadzić do tej prostej definicji: Otrzymuje żądanie od klienta i zwraca klientowi odpowiedź. To podstawowa definicja i jednocześnie minimalne wymaganie dla każdego kontrolera. To, co robi pomiędzy tymi dwoma czynnościami, jest zazwyczaj uważane za „działanie” kontrolera (lub „implementację trasy”). Działa jako drugi punkt wejścia do aplikacji (pierwszym jest żądanie) dla klienta, który wysyła ładunek żądania (do którego przejdziemy później) do aplikacji, oczekując jakiejś odpowiedzi (w postaci strony z potwierdzeniem sukcesu, przekierowania, strony błędu lub dowolnego innego rodzaju odpowiedzi HTTP).

Kontroler robi (zasadniczo) to samo, co definicja trasy z funkcją anonimową ustawioną jako „akcję” w momencie trafienia na tę trasę. Różnica polega na tym, że kontroler dobrze radzi sobie z rozdzieleniem zadań, podczas gdy trasa jest definiowana bezpośrednio w odniesieniu do rzeczywistej URL definicja, która w zasadzie oznacza, że ​​łączymy przypisany trasie adres URI z implementacją trasy, czyli kodem, który jest wykonywany po trafieniu na tę trasę.

Na przykład poniższe dwa fragmenty kodu osiągną ten sam cel:

Przykład nr 1: Definicja i implementacja trasy w pojedynczym wywołaniu metody (w pliku tras web.php)

//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);
});

Przykład nr 2: Definicja trasy znajduje się w pliku routes/web.php, ale jej implementacja znajduje się w klasie /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);
}
}

Chociaż przykład Laravel nr 2 wydaje się wymagać o wiele więcej pracy (co nie jest prawdą – to tylko odrobina więcej kodu), spójrzmy na korzyści, jakie zyskujemy, umieszczając logikę akcji dla danej trasy „hello-world” wewnątrz kontrolera zamiast definiować trasę jako funkcję wywołania zwrotnego:

1. Nasza logika jest wyraźnie oddzielona do własnej klasy (separacja zagadnień).
2. Nasz kontroler jest skonfigurowany do późniejszej rozbudowy, jeśli zajdzie potrzeba dodania do niego dodatkowych funkcji. Załóżmy, że chcemy dodać funkcję „pożegnania świata”. W takim przypadku zmienilibyśmy nazwę kontrolera na bardziej ogólną „HelloController”, a następnie zdefiniowali dwie oddzielne metody: Witam() oraz do widzenia(). Musielibyśmy także zdefiniować dwie oddzielne trasy, które wyznaczałyby mapę /Witam oraz /do widzenia URI do odpowiedniej metody w kontrolerze. Jest to pożądane w porównaniu z rozbudową pliku tras, w którym implementacja każdej trasy jest definiowana jako funkcja wywołania zwrotnego.
3. Laravel posiada wbudowaną możliwość buforowania wszystkich definicji tras w aplikacji, dzięki czemu przyspiesza czas znalezienia danej trasy (zwiększa wydajność aplikacji); Jednak będziesz mógł z tego skorzystać tylko wtedy, gdy wszystkie zdefiniowane trasy w aplikacji zostaną skonfigurowane przy użyciu mapy specyficznej dla kontrolerapings (patrz przykład nr 2 powyżej).

Uruchommy to polecenie, które wygeneruje dla nas nowy kontroler.

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

W zasadzie to polecenie generuje stub dla kontrolera o nazwie „UploadController” w głównym katalogu kontrolera: /app/Http/Controllers/UploadController.php. Możesz otworzyć ten plik i zajrzeć do niego. To bardzo proste, ponieważ jest to jedynie zmodyfikowana wersja kontrolera, z poprawną ścieżką do przestrzeni nazw i wymaganymi klasami, z których się rozwija.

Generowanie żądania

Zanim przejdziemy dalej w tym samouczku PHP Laravel i wprowadzimy kilka zmian w wygenerowanym stubie kontrolera UploadController, bardziej sensowne będzie najpierw utworzenie klasy żądania. Wynika to z faktu, że metoda kontrolera obsługująca żądanie musi podać wskazówkę typu obiektu żądania w swoim podpisie, co pozwala jej na automatyczną walidację przychodzących danych formularza (zgodnie z metodą rules(); więcej o tym później). Teraz ponownie użyjmy polecenia artisan, aby wygenerować nasz stub żądania:

php artisan make:request UploadFileRequest

To polecenie wygeneruje plik o nazwie UploadFileRequest w katalogu app/Http/Requests/UploadFileRequest. Otwórz plik-stub i zajrzyj do niego. Przekonasz się, że jest bardzo prosty i zawiera tylko dwie metody: authorize() i rules().

Tworzenie logiki walidacji

Zmodyfikujmy plik żądania, aby spełniał potrzeby naszej aplikacji. Zmodyfikuj plik tak, aby wyglądał następująco:

<?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'
];
}
}

Niewiele zmian, ale zauważ, że metoda authorize() zwraca teraz wartość true zamiast false. Ta metoda decyduje, czy zezwolić na przesłanie żądania do aplikacji. Jeśli jest ustawiona na false, uniemożliwia przesłanie żądania do systemu. Byłoby to bardzo przydatne miejsce do przeprowadzania kontroli autoryzacji użytkownika lub innej logiki, która może decydować o tym, czy żądanie może zostać przekazane do kontrolera. Na razie zwracamy tutaj wartość true, aby zezwolić wszystkim na korzystanie z żądania.

Druga metoda, rules(), to miejsce, w którym cała magia walidacji wchodzi w grę. Pomysł jest prosty: zwróć tablicę zawierającą zestaw reguł w postaci:

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

Istnieje wiele różnych ograniczeń walidacyjnych, które są obsługiwane przez Laravel od razu po wyjęciu z pudełka. Aby uzyskać pełną listę, sprawdź dokumentację online w tym miejscuW naszej aplikacji do przesyłania danych będą dwa pola przekazywane za pomocą żądania POST z formularza na froncie. Parametr fileName musi znajdować się w treści formularza (czyli być wymagany) i jest używany jako nazwa pliku, pod którą plik zostanie zapisany w pamięci (odbywa się to w kontrolerze; omówimy to nieco później). Określamy również, że nazwa pliku musi być ciągiem znaków, dodając znak pionowej kreski (|) i słowo „ciąg znaków”. Ograniczenia są zawsze rozdzielane pionowymi kreskami, co pozwala na określenie dodatkowych kryteriów dla danego pola w jednym wierszu.

Drugim parametrem jest userFile, który jest rzeczywistym plikiem przesyłanym przez użytkownika z formularza na stronie internetowej. Parametr userFile jest również wymagany i musi być plikiem. Uwaga: Gdybyśmy oczekiwali, że przesłany plik będzie obrazem, zastosowalibyśmy ograniczenie dotyczące obrazu, które ograniczyłoby akceptowane typy plików jako jeden z popularnych typów obrazów (jpeg, png, bmp, gif lub svg). Ponieważ chcemy umożliwić użytkownikowi przesłanie dowolnego typu pliku, po prostu zastosujemy ograniczenie dotyczące walidacji pliku.

To właściwie wszystko, co dotyczy obiektu żądania. Jego głównym zadaniem jest po prostu przechowywanie akceptowalnego zestawu kryteriów (ograniczeń), które parametry treści formularza muszą spełniać, aby przejść dalej w aplikacji. Warto również zauważyć, że te dwa pola (userFile i fileName) muszą być również określone w kodzie HTML w formie pól wejściowych (z nazwą pola odpowiadającą nazwie w obiekcie żądania).

Możesz zapytać: to definiuje cechy, jakie powinien zawierać wniosek o formularz, ale gdzie odbywa się faktyczne sprawdzenie tych ograniczeń? Omówimy to później.

Modyfikowanie kontrolera

Otwórz app/Http/Controllers/UploadController i wprowadź następujące zmiany:

<?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 process(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'); //so 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
}
}

To dość proste podejście do zapisywania przesłanych plików na dysku. Oto opis metody process() powyżej:

• Podaj wskazówkę dotyczącą klasy żądania w metodzie kontrolera realizującej główną funkcjonalność, dzięki czemu będziemy mogli automatycznie sprawdzić poprawność przychodzących danych.
• Pobierz plik z (teraz zweryfikowanego) obiektu żądania wewnątrz metody kontrolera.
• Pobierz nazwę pliku z żądania.
• Wygeneruj ostateczną nazwę pliku, pod którą zostanie zapisany plik. Metoda getClientOriginalExtension() po prostu pobiera oryginalne rozszerzenie przesłanego pliku.
• Zapisz plik w lokalnym systemie plików, używając metody storeAs(), przekazując nazwaną ścieżkę wewnątrz katalogu /storage jako pierwszy argument i nazwę pliku, pod którym ma zostać zapisany, jako drugi.
• Zwróć odpowiedź JSON informującą, że żądanie zakończyło się pomyślnie.

Szablon ostrza

Ostatnim ważnym elementem tej układanki jest szablon Blade, który będzie zawierał wszystkie elementy HTML, CSS i JavaSkrypt do naszej prostej aplikacji. Oto kod; wyjaśnimy go później.

<body>
<h1>Upload a file</h1>
<form id="uploadForm" name="uploadForm" action="{{route('process')}}" 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>

Oto, co nasze / Przekazać plik strona wygląda następująco:

To bardzo typowy przykład pliku typu blade zawierającego formularz HTML i JavaSkrypt/jQuery do dodawania funkcjonalności asynchronicznej (dzięki której strona się nie odświeża). Jest podstawowy tag bez atrybutu metody (co wyjaśnimy za chwilę) i z ciekawym atrybutem akcji o wartości {{route('process')}}. W Blade jest to znane jako Dyrektywa. Dyrektywa to po prostu wymyślna nazwa funkcji; są to funkcje specyficzne dla szablonów Blade, które wykonują różne operacje typowe dla tworzenia stron internetowych i aplikacji internetowych. Aby lepiej zrozumieć wszystkie przydatne funkcje Blade, zapoznaj się z dokumentacją. w tym miejscuW powyższym przypadku używamy dyrektywy route do wygenerowania URL za przesłanie formularza.

Pamiętaj, że zdefiniowaliśmy nasze trasy wcześniej w aplikacji w pliku web.php, określając łatwą do zapamiętania nazwę dla każdej z nich. Dyrektywa {{route()}} akceptuje nazwę trasy, wyszukuje ją na liście tras w pamięci podręcznej i generuje pełną URL na podstawie definicji tej trasy w pliku web.php. W tym pierwszym przypadku określamy, że chcemy, aby formularz wysyłał przesłane dane do /process URL naszej aplikacji, która jest zdefiniowana jako POST trasa.

Następną rzeczą, którą mogłeś zauważyć, jest znacznik @csrf tuż pod znacznikiem otwierającym formularz. W systemie Blade ten znacznik generuje parametr _token w formularzu, który jest sprawdzany w aplikacji przed dopuszczeniem danych formularza do przetworzenia. Zapewnia to prawidłowe źródło danych w formularzu i zapobiega atakom typu cross-site request forgery. Więcej informacji na ten temat znajdziesz w artykule. docs.

Następnie definiujemy nasz formularz jako normalny; należy jednak pamiętać, że nazwy parametrów formularza, userFile i fileName, są dokładnie to samo zdefiniowane w naszym obiekcie żądania. Jeśli zapomnimy o uwzględnieniu danych wejściowych dla danego parametru zdefiniowanego w obiekcie żądania (lub popełnimy błąd ortograficzny), żądanie zakończy się niepowodzeniem i zwrócony zostanie błąd, uniemożliwiając pierwotnemu żądaniu formularza dotarcie do metody kontrolera znajdującej się pod adresem UploadController@process.

Wypróbuj to i prześlij kilka plików do aplikacji za pomocą tego formularza. Następnie przejdź do /lista stronę, na której możesz zobaczyć zawartość folderu przesyłania, wraz z listą przesłanych plików w tabeli:

Szerszy

Cofnijmy się o krok i przyjrzyjmy się temu, co zrobiliśmy w tym samouczku dotyczącym Laravela.

Poniższy diagram przedstawia aplikację w jej obecnym stanie (bez szczegółów ogólnych):

Należy pamiętać, że obiekt żądania, który skonstruowaliśmy na początku tego samouczka Laravel, powinien mieć te same parametry zdefiniowane w metodzie rules, co w formularzu w szablonie Blade (jeśli nie, przeczytaj ponownie sekcję „Tworzenie logiki walidacji”). Użytkownik wchodzi do formularza na stronie internetowej renderowanej przez silnik szablonu Blade i przesyła formularz. Kod jQuery szablonu na dole zatrzymuje domyślne przesyłanie (które automatycznie przekierowałoby na osobną stronę), tworzy żądanie Ajax, ładuje żądanie z danymi formularza i przesłanym plikiem, a następnie przesyła całość do pierwszej warstwy naszej aplikacji: żądania.

Obiekt żądania jest wypełniany poprzez skojarzenie parametrów w metodzie rules() z przesłanymi parametrami formularza, a następnie waliduje dane zgodnie z każdą określoną regułą. Jeśli wszystkie reguły są spełnione, żądanie jest przekazywane do dowolnej metody kontrolera odpowiadającej wartościom zdefiniowanym w pliku trasy web.php. W tym przypadku to metoda process() kontrolera UploadController wykonuje zadanie. Po dotarciu do kontrolera wiemy już, że żądanie przeszło walidację, więc nie musimy ponownie sprawdzać, czy podana nazwa pliku jest w rzeczywistości ciągiem znaków, a parametr userFile faktycznie zawiera jakiś typ pliku. Możemy kontynuować normalnie.

Metoda kontrolera pobiera następnie zweryfikowane parametry z obiektu żądania, generuje pełną nazwę pliku poprzez połączenie przekazanego parametru fileName z oryginalnym rozszerzeniem userFile, zapisuje plik w katalogu w naszej aplikacji, a następnie zwraca prostą odpowiedź zakodowaną w formacie JSON, potwierdzającą pomyślne wykonanie żądania. Odpowiedź jest odbierana przez logikę jQuery, która wykonuje kilka dodatkowych zadań związanych z interfejsem użytkownika, takich jak wyświetlanie komunikatu o powodzeniu (lub błędzie) przez 5 sekund, a następnie ukrywanie go, a także czyszczenie poprzednich wpisów w formularzu. Dzięki temu użytkownik ma pewność, że żądanie zostało wykonane pomyślnie i może przesłać kolejny plik, jeśli zechce.

Zwróć również uwagę na powyższy diagram, gdzie dokładnie przebiega granica między klientem a serwerem. Ta koncepcja jest absolutnie kluczowa dla zrozumienia i pomoże Ci rozwiązać problemy i kwestie, które możesz napotkać w przyszłości, na przykład podczas żonglowania wieloma asynchronicznymi żądaniami, które mogą wystąpić w dowolnym momencie. Separacja znajduje się tuż na granicy obiektu żądania. Sam obiekt żądania można traktować jako „bramę” do reszty aplikacji. Wykonuje on początkową walidację i rejestrację wartości formularza przekazanych z przeglądarki internetowej. Jeśli zostaną uznane za prawidłowe, kontynuuje działanie do kontrolera. Wszystko, co było wcześniej, znajduje się na froncie („klient” dosłownie oznacza „na komputerze użytkownika”). Odpowiedź jest zwracana z aplikacji z powrotem do strony klienta, gdzie nasz kod jQuery cierpliwie nasłuchuje jej nadejścia i po jej otrzymaniu wykonuje kilka prostych zadań interfejsu użytkownika.

Omówiliśmy również wiele ważnych, często zadawanych pytań Pytania do rozmowy kwalifikacyjnej związane z Laravelem i PHP zarówno nowicjuszom, jak i doświadczonym kandydatom na znalezienie właściwej pracy.

FAQ