초보자를 위한 라라벨 튜토리얼
라라벨이란?
Laravel PHP용 오픈 소스 웹 MVC 프레임워크입니다. Laravel은 전용 종속성 관리자가 포함된 모듈식 패키징 시스템, 관계형 데이터베이스에 대한 액세스, 애플리케이션 배포 및 유지 관리를 위한 기타 유틸리티와 같은 기능을 통해 PHP 웹 애플리케이션을 쉽게 개발할 수 있는 강력한 프레임워크입니다.
Laravel은 Taylor Otwell에 의해 만들어졌습니다. 2011년 1월(버전 XNUMX) 첫 출시 이후 웹 개발 업계의 PHP 프레임워크 부문에서 꾸준히 인기를 끌었습니다. 이러한 인기의 상당 부분은 재고와 함께 제공되는 많은 개발자 우선 기능에 기인할 수 있습니다.
왜 라라벨인가?
2000년경 대부분 PHP 코드 절차적이며 스파게티 코드가 엉켜있는 "스크립트" 형태로 발견될 수 있습니다. 가장 단순한 페이지에도 우려의 분리, 따라서 애플리케이션이 유지 관리의 악몽으로 빠르게 성장하는 것은 상당히 쉬웠습니다. 세상에는 더 나은 것이 필요했습니다...다양한 웹 애플리케이션 문제에 대해 절실히 필요한 해결책과 더 나은 솔루션을 제공하려는 PHP 버전 5와 다양한 PHP 프레임워크를 입력하세요.
그 이후로 우리는 오늘날 존재하고 사용되고 있는 인기 있는 프레임워크의 길을 닦을 많은 프레임워크가 출시되는 것을 보았습니다. 오늘날, 상위 3개는 (저희의 의견으로는) Zend Framework, Symfony, 그리고 물론 Laravel입니다. 이러한 프레임워크는 각각 유사한 원칙에 따라 만들어졌고 (기본적으로) 동일한 일반적인 문제를 해결하는 데 중점을 두고 있지만, 주요 차이점은 구현 방식입니다. 각각 문제를 해결하는 방법에 대한 고유한 특징이 있습니다. 각각에서 생성된 코드를 살펴보면 서로를 구분하는 꽤 견고한 선이 있다는 것을 알 수 있습니다. 저희의 겸손한 의견으로는 Laravel 프레임워크가 최고입니다.
전단지에 포함된 링크에 대해 더 알아보기 Laravel과 CodeIgniter의 차이점
Composer로 Laravel을 다운로드하고 설치하는 방법
주의사항 로컬 시스템에 이미 PHP 사본이 설치되어 있다고 가정합니다. 그렇지 않은 경우 설치 방법을 읽어보세요. LINK
Composer는 패키지이자 종속성 관리자입니다. 설치하려면 터미널을 열고 새 디렉토리로 cd를 실행합니다. 다음 명령을 실행합니다.
curl -Ss getcomposer.org/installer | php
이 명령의 결과는 다음과 같습니다.
주의 사항 Laravel 설정에 대한 더 광범위한 지침은 Laravel 문서를 참조하세요. LINK.
Laravel을 설치하는 데 사용하는 composer.phar 스크립트를 다운로드하고 컴파일하는 것을 볼 수 있습니다. 새로운 Laravel 애플리케이션을 설정하는 방법은 여러 가지가 있지만, Laravel composer 스크립트를 통해 이를 수행하겠습니다. 이 스크립트를 설치하려면 다음을 실행하세요.
composer global require laravel/installer
다음과 같이 보일 것입니다:
이렇게 하면 모든 프레임워크 파일 자체와 필요한 모든 종속성이 다운로드되어 설치됩니다. 패키지는 공급업체 디렉토리에 저장됩니다. 다운로드하고 설치한 후에는 다음 명령을 실행하기만 하면 됩니다.
laravel new uploadApp
다음과 같은 출력이 표시됩니다.
Composer는 Laravel이 실행하기 위해 필요한 모든 패키지를 설치합니다. 몇 분이 걸릴 수 있으므로 인내심을 가지세요. 완료되면 ls -al 명령을 실행하여 설치된 내용을 살펴보세요.
다음은 일반적인 Laravel 애플리케이션의 디렉터리에 대한 간략한 설명입니다:
- 앱/ : 이는 애플리케이션 코드가 있는 소스 폴더입니다. 모든 컨트롤러, 정책 및 모델이 이 폴더 안에 있습니다.
- 부트스트랩/ : 애플리케이션의 시작 스크립트와 몇 가지 클래스 맵 파일을 보유합니다.
- 구성/ : 앱의 구성 파일을 보관합니다. 이는 일반적으로 직접 수정되지 않고 대신 앱 루트의 .env(환경) 파일에 설정된 값에 의존합니다.
- 데이터베이스/ : 마이그레이션, 시드 및 테스트 팩토리를 포함한 데이터베이스 파일을 보관합니다.
- 공공의/ : 컴파일된 자산과 물론 index.php 파일을 포함하는 공개적으로 액세스 가능한 폴더
- 자원/ : javascript 파일, 언어 파일, CSS/SASS 파일 및 애플리케이션에 사용되는 모든 템플릿(블레이드 템플릿이라고 함)과 같은 프런트 엔드 자산을 포함합니다.
- 경로/ : 애플리케이션의 모든 경로가 여기에 있습니다. 경로에는 몇 가지 다른 "범위"가 있지만 우리가 집중할 것은 web.php 파일입니다.
- 저장/ : 애플리케이션에서 사용하는 모든 임시 캐시 파일, 세션 파일, 컴파일된 보기 스크립트 및 로그 파일
- 테스트/ : 단위 테스트, 기능 테스트 등 애플리케이션에 대한 테스트 파일이 포함되어 있습니다.
- 공급업체/ : composer로 설치된 모든 종속성 패키지
이제 앱의 나머지 부분을 빌드하고 특별한 artisan 명령을 사용하여 실행해 보겠습니다(Apache 또는 nginx와 같은 웹 서버를 설치하고 구성하는 번거로움을 줄이기 위해). .env 파일에는 /config 디렉터리의 파일이 애플리케이션을 구성하는 데 사용하는 모든 구성 값이 포함되어 있습니다. 그 안에는 애플리케이션 내부에서 사용되는 다양한 매개변수의 구성 값이 표시됩니다.
애플리케이션 설계: 요구 사항에 대한 빠른 요약
이 온라인 Laravel 튜토리얼에서 우리는 다음 두 가지 작업만 수행하는 매우 간단한 애플리케이션을 구축할 것입니다:
- 웹 양식에서 파일 업로드 처리
- 이전에 업로드한 파일을 다른 페이지에 표시합니다.
이 프로젝트의 경우 애플리케이션은 쓰기 전용입니다. 즉, 사용자는 파일을 작성하고 자신이 업로드한 파일 목록을 볼 수만 있습니다. 이 애플리케이션은 매우 기본적이지만 Laravel 기술과 지식을 쌓기 시작하는 데 좋은 연습이 될 것입니다. 간결성을 위해 데이터베이스 모델링, 마이그레이션 및 인증을 제외했지만 실제 애플리케이션에서는 이러한 사항을 추가로 고려해야 합니다.
다음은 애플리케이션이 예상대로 작동하도록 하기 위해 필요한 구성 요소 목록입니다.
- A 길 외부 세계(인터넷)가 애플리케이션을 사용할 수 있도록 허용하고 업로드된 파일을 저장하기 위한 논리가 있는 위치를 가리키는 엔드포인트를 지정합니다.
- A 제어 장치 응답 흐름에 대한 요청을 처리하는 것
- A 이 템플릿 이전에 업로드한 파일 목록과 실제 업로드 양식 자체를 표시하는 데 사용됩니다.
- A 의뢰 컨트롤러가 웹 양식에서 전달된 데이터의 유효성을 검사하는 데 사용할 것입니다.
경로란 무엇입니까?
Laravel의 경로는 기본적으로 애플리케이션이 제공하는 일부 기능에 대한 "포인터" 역할을 하는 URI로 지정된 끝점입니다. 가장 일반적으로 경로는 단순히 컨트롤러의 메서드를 가리키며 어떤 HTTP 메서드가 해당 URI에 도달할 수 있는지도 지정합니다. 경로가 항상 컨트롤러 방법을 의미하는 것은 아닙니다. 정의된 클로저나 익명 함수에 애플리케이션 실행을 전달할 수도 있습니다.
경로를 사용하는 이유는 무엇입니까?
경로는 프로젝트 루트 디렉토리 내의 /routes 폴더 아래에 있는 파일에 저장됩니다. 기본적으로 애플리케이션의 다른 "측면"에 해당하는 몇 가지 다른 파일이 있습니다("측면"은 육각형 아키텍처 방법론에서 유래). 여기에는 다음이 포함됩니다.
- web.php "브라우저" 기반 경로를 향한 공용입니다. 이는 가장 일반적이며 웹 브라우저에 의해 공격을 받는 것입니다. 웹 미들웨어 그룹을 통해 실행되며 다음을 위한 기능도 포함합니다. csrf 보호 (양식 기반 악성 공격 및 해킹으로부터 방어하는 데 도움이 됨) 일반적으로 어느 정도의 "상태"를 포함합니다(즉, 세션을 활용한다는 의미입니다).
- api.php API 그룹에 해당하는 경로이므로 기본적으로 API 미들웨어가 활성화됩니다. 이러한 경로는 상태 비저장이며 세션이나 교차 요청 메모리가 없습니다. 하나의 요청은 다른 요청과 데이터나 메모리를 공유하지 않으며 각 요청은 자체 캡슐화됩니다.
- console.php 이 경로는 앱을 위해 생성한 사용자 정의 artisan 명령에 해당합니다.
- channels.php 이벤트 방송을 위한 경로를 등록합니다.
이때 주목해야 할 핵심 파일은 브라우저별 파일인 web.php 입니다. 기본적으로 정의된 경로가 이미 하나 있는데, 이는 애플리케이션의 웹 루트로 이동할 때 바로 누르는 경로입니다(웹 루트는 공용 디렉터리에 있음). 업로드 애플리케이션이 작동하려면 세 가지 다른 경로가 필요합니다.
- /upload 이는 파일 업로드를 위한 웹 양식을 표시하는 기본 페이지의 URI입니다.
- /process 이는 /upload URI에 있는 양식이 양식 제출 데이터를 (양식의 "작업")에 게시하는 위치입니다.
- /list 사이트에 업로드된 모든 파일을 나열합니다.
주의 업로드 양식과 파일 목록을 단일 페이지에 표시하기 위한 모든 로직을 표시하려는 경우 /list 엔드포인트가 필요하지 않을 수 있지만 현재 주제에 좀 더 많은 문제를 추가하기 위해 지금은 이들을 별도로 유지했습니다. .
//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');
이 Laravel 프레임워크 튜토리얼에서는 원하는 각 경로에 대해 사용 가능한 HTTP 특정 요청 메서드(get(), post(), put(), delete(), patch() 또는 options() ). 이들 각각에 대한 분석을 보려면 다음을 확인하세요. 이 밖으로. 이러한 메서드가 수행하는 작업은 해당 경로에 액세스할 수 있는 HTTP 동사를 지정하는 것입니다. 둘 이상의 HTTP 동사를 허용할 수 있는 경로가 필요한 경우(초기 데이터와 게시된 양식 데이터를 모두 표시하기 위해 단일 페이지를 사용하는 경우일 수 있음) Route::any( ) 방법.
Route::get()과 Route::post() 메서드(및 Route facade에 있는 다른 HTTP 동사 관련 메서드)의 두 번째 인수는 허용된 HTTP 요청(GET, POST, PATCH 등)으로 경로의 엔드포인트에 도달하면 실행되는 특정 Controller와 해당 컨트롤러 내에 있는 메서드의 이름입니다. 세 경로 모두에 UploadController를 사용하고 다음과 같은 방식으로 지정했습니다.
각 경로에서 호출하는 마지막 메서드는 단일 문자열을 인수로 받아들이고 기억하기 쉬운 이름으로 특정 경로에 어느 정도 "태그"를 지정하는 데 사용되는 name() 함수입니다. 업로드, 처리 및 나열). URL의 이름이 정확히 동일할 때 각 경로에 고유한 이름을 지정하는 기능이 그다지 좋아 보이지는 않지만 /users/profile/dashboard/config와 같은 특정 경로가 있는 경우에는 실제로 유용합니다. profile-admin 또는 user-config로 기억하기가 더 쉽습니다.
Facades에 대한 참고사항:
- Facade는 애플리케이션의 서비스 컨테이너에서 사용할 수 있는 클래스에 대한 "정적" 인터페이스를 제공합니다.
- 수동으로 삽입하거나 구성해야 하는 긴 클래스 이름을 기억하지 않고도 Laravel의 기능을 사용할 수 있도록 간결하고 기억에 남는 구문을 제공합니다.
이 Laravel 프레임워크 튜토리얼의 위 경로 정의에서는 새 Illuminate/Routing/Router 객체를 수동으로 인스턴스화하고 해당 객체에 해당하는 메서드를 호출하는 대신 Route 파사드를 사용합니다. 단지 타이핑을 절약하기 위한 단축키일 뿐입니다. Facade는 Laravel 프레임워크 전반에 걸쳐 많이 사용됩니다. 따라서 Facade에 더 익숙해질 수 있고 익숙해져야 합니다. Facades에 대한 문서를 찾을 수 있습니다. LINK.
컨트롤러란 무엇입니까?
컨트롤러는 Laravel이 기반을 둔 "MVC"(모델-뷰-컨트롤러) 아키텍처의 "C"입니다. 컨트롤러의 작업은 이 간단한 정의로 요약할 수 있습니다. 클라이언트로부터 요청을 받고 클라이언트에 응답을 반환합니다. 이는 기본 정의이며 특정 컨트롤러의 최소 요구 사항이기도 합니다. 이 두 가지 사이에서 수행하는 작업은 일반적으로 컨트롤러의 "작업"(또는 "경로 구현")으로 간주됩니다. 이는 애플리케이션에 대한 두 번째 진입점(첫 번째는 요청) 역할을 하며, 클라이언트는 요청 페이로드(다음에 얻을 것임)를 애플리케이션에 보내고 어떤 유형의 응답(예제 형식)을 기대합니다. 성공 페이지, 리디렉션, 오류 페이지 또는 기타 모든 종류의 HTTP 응답).
컨트롤러는 해당 경로에 도달할 때 "작업"으로 설정된 익명 함수를 사용하여 경로 정의와 (기본적으로) 동일한 작업을 수행합니다. 차이점은 경로가 실제 URL 정의에 인라인으로 정의되는 동안 컨트롤러가 문제의 분리를 잘 유지한다는 것입니다. 이는 기본적으로 경로의 할당된 URI를 경로의 구현 또는 해당 경로가 실행될 때 실행되는 코드와 결합한다는 것을 의미합니다. 때리다.
예를 들어, 다음 두 코드는 동일한 결과를 달성합니다.
예제 #1: 단일 메서드 호출 내에서 경로 정의 및 구현(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); });
예제 #2: Route의 정의는 Routes/web.php 내에 있지만 구현은 /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); } }
Laravel 예제 #2는 훨씬 더 많은 작업처럼 보이지만(그렇지는 않습니다. 단지 약간의 코드만 추가하면 됩니다) 대신 컨트롤러 내부에 주어진 "hello-world" 경로에 대한 액션 로직을 배치함으로써 얻을 수 있는 이점을 살펴보십시오. 콜백 함수로 경로 정의를 사용합니다.
- 우리의 논리는 자체 클래스로 깔끔하게 분리됩니다(관심사 분리).
- 나중에 추가 기능을 추가해야 하는 경우를 대비해 컨트롤러를 확장할 수 있도록 설정했습니다. 예를 들어 "안녕 세상" 기능을 추가하고 싶을 수 있습니다. 이 경우 컨트롤러 이름을 보다 일반적인 "HelloController"로 바꾼 다음 두 개의 별도 메서드를 정의합니다. 안녕하세요() 그리고 안녕히 가세요(). 또한 다음을 매핑하는 두 개의 별도 경로를 정의해야 합니다. /안녕하세요 그리고 / 안녕 컨트롤러의 적절한 메서드에 대한 URI입니다. 이는 콜백 함수로 정의된 각 경로의 구현을 사용하여 경로 파일을 두껍게 만드는 것과 비교할 때 바람직합니다.
- Laravel에는 애플리케이션의 모든 경로 정의를 캐시하는 기능이 내장되어 있어 주어진 경로를 찾는 데 걸리는 시간을 단축합니다(애플리케이션 성능 향상). 그러나 애플리케이션 내부에 정의된 모든 경로가 컨트롤러별 매핑을 사용하여 구성된 경우에만 이를 활용할 수 있습니다(위의 예 #2 참조).
새 컨트롤러를 생성하는 이 명령을 실행해 보겠습니다.
// ...inside the project's root directory: php artisan make:controller UploadController
기본적으로 이 명령이 수행하는 작업은 /app/Http/Controllers/UploadController.php의 기본 컨트롤러 디렉터리 내부에 "UploadController"라는 컨트롤러에 대한 스텁을 생성하는 것입니다. 자유롭게 해당 파일을 열고 살펴보세요. 이는 올바른 네임스페이스 경로와 확장되는 필수 클래스를 포함하는 컨트롤러의 스텁아웃 버전일 뿐이므로 매우 간단합니다.
요청 생성
이 PHP Laravel 튜토리얼을 계속 진행하고 UploadController의 생성된 스텁에 몇 가지 변경을 하기 전에 먼저 요청 클래스를 만드는 것이 더 합리적이라고 생각합니다. 이는 요청을 처리하는 컨트롤러 메서드가 서명에서 요청 객체를 유형 힌트로 지정해야 하기 때문에 들어오는 양식 데이터를 자동으로 검증할 수 있기 때문입니다(rules() 메서드에서 지정한 대로. 나중에 자세히 설명하겠습니다...). 지금은 artisan 명령을 다시 사용하여 요청 스텁을 생성해 보겠습니다.
php artisan make:request UploadFileRequest
이 명령은 app/Http/Requests/UploadFileRequest 내에 UploadFileRequest라는 파일을 생성합니다. 스텁을 열고 살짝 살펴보세요. Authorize()와 규칙이라는 두 가지 메서드만 포함되어 있어 매우 간단하다는 것을 알 수 있습니다.
검증 로직 생성
애플리케이션의 요구 사항을 충족하도록 요청 스텁을 수정해 보겠습니다. 다음과 같이 파일을 수정합니다.
<?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' ]; } }
많은 변경 사항은 아니지만 이제 Authorize() 메서드가 false 대신 true를 반환한다는 점에 유의하세요. 이 메소드는 요청이 애플리케이션에 들어가는 것을 허용할지 여부를 결정합니다. false로 설정되면 요청이 시스템에 입력되는 것을 중지합니다(일반적으로 컨트롤러의 메서드임). 이는 사용자에 대한 인증 확인이나 요청이 컨트롤러로 이동할 수 있는지 여부를 결정할 수 있는 기타 로직을 배치하는 데 매우 편리한 장소입니다. 지금은 모든 것이 요청을 사용할 수 있도록 여기에서 true를 반환합니다.
다른 방법인 rule()은 유효성 검사와 관련하여 모든 마법이 작용하는 곳입니다. 아이디어는 간단합니다. 다음 형식의 규칙 집합을 포함하는 배열을 반환합니다.
'formFieldName' => 'constraints this field has separated by pipe characters (|)'
Laravel에서 바로 지원하는 다양한 검증 제약 조건이 있습니다. 전체 목록은 온라인 설명서를 확인하세요. LINK. 업로드 애플리케이션의 경우 프런트 엔드의 양식에서 POST 요청을 통해 전달되는 두 개의 필드가 있습니다. fileName 매개변수는 양식 본문(즉, 필수)에 포함되어야 하며 저장소에 파일을 저장할 파일 이름으로 사용됩니다(이 작업은 컨트롤러에서 수행합니다. 나중에 자세히 설명하겠습니다). 또한 파이프 문자(|)와 'string'이라는 단어를 추가하여 파일 이름이 문자열이어야 함을 지정합니다. 제약 조건은 항상 파이프로 구분되므로 주어진 필드에 대한 추가 기준을 한 줄로 지정할 수 있습니다! 얼마나 강력한지요!
두 번째 매개변수인 userFile 은 사용자가 웹페이지의 양식에서 업로드하는 실제 파일입니다. UserFile도 필요하며 절대로 필요한 것 파일이 되십시오. 참고 : 업로드된 파일이 이미지일 것으로 예상했다면 대신 이미지 제약 조건을 사용하여 널리 사용되는 이미지 유형(jpeg, png, bmp, gif 또는 svg) 중 하나로 허용되는 파일 유형을 제한합니다. 사용자가 모든 유형의 파일을 업로드할 수 있도록 허용하고 싶기 때문에 파일 유효성 검사 제약 조건을 고수하겠습니다.
이것이 요청 객체의 전부입니다. 주요 임무는 응용 프로그램을 더 깊이 진행하기 위해 양식의 본문 매개변수가 충족해야 하는 허용 가능한 기준(제약 조건) 세트를 보유하는 것입니다. 또 다른 주목해야 할 점은 이 두 필드(userFile 및 filename)도 HTML 코드 내에서 입력 필드 형식(요청 개체 내부의 이름에 해당하는 필드 이름 포함)으로 지정해야 한다는 것입니다.
당신은 다음과 같이 질문할 수도 있습니다. 이것이 양식 요청에 포함되어야 하는 특성을 정의하는 것은 확실하지만 이러한 제약 조건에 대한 실제 확인은 어디에서 수행됩니까? 그 내용은 다음에 다루겠습니다.
컨트롤러 수정
앱/Http/Controllers/UploadController를 열고 다음과 같이 변경합니다.
<?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 } }
따라서 업로드된 파일을 디스크에 저장하는 것은 매우 간단한 접근 방식입니다. 위의 upload() 메소드에 대한 분석은 다음과 같습니다.
- 들어오는 데이터를 자동으로 확인할 수 있도록 '고기와 감자' 기능을 수행하는 컨트롤러 메서드에서 요청 클래스를 유형 힌트로 지정하세요.
- 컨트롤러 메소드 내부의 (이제 검증된) 요청 객체에서 파일을 가져옵니다(이 경우 이름을 upload()로 지정했지만 store()와 같이 보다 표준화된 이름으로 이름을 지정할 수도 있음).
- 요청에서 파일 이름을 가져옵니다.
- 파일을 저장하는 데 사용할 최종 파일 이름을 생성합니다. getClientOriginalExtension() 메소드는 업로드된 파일의 원래 확장자를 가져옵니다.
- storeAs() 메소드를 사용하여 파일을 로컬 파일 시스템에 저장하고 /storage 디렉토리 내부의 명명된 경로를 첫 번째 인수로 전달하고 파일 이름을 두 번째 인수로 전달합니다.
- 요청이 성공했음을 나타내는 JSON 응답을 반환합니다.
블레이드 템플릿
이 퍼즐의 마지막 주요 조각은 블레이드 템플릿으로, 간단한 애플리케이션의 모든 HTML, CSS 및 자바스크립트를 보관합니다. 코드는 다음과 같습니다. 나중에 설명하겠습니다.
<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>
여기에 우리의 /업로드 페이지는 다음과 같습니다:
이것은 HTML 폼과 비동기 기능을 추가하기 위한 자바스크립트/jQuery를 포함하는 블레이드 파일의 매우 전형적인 예입니다(그래서 페이지가 새로 고쳐지지 않습니다). 기본이 있습니다. 메서드 속성이 없는 태그(잠시 후에 설명하겠습니다)와 값 {{route('file.upload')}}을 가진 궁금한 액션 속성이 있습니다. Blade에서는 이것을 지침. 지시어는 함수의 멋진 이름일 뿐입니다. 이는 블레이드 템플릿에 특화된 함수로, 웹 페이지와 웹 애플리케이션을 구성하는 데 공통적인 다양한 작업을 수행합니다. 블레이드가 할 수 있는 모든 멋진 일을 더 잘 이해하려면 문서를 확인하세요. LINK. 위의 경우, 우리는 양식 제출을 위한 URL을 생성하기 위해 경로 지시문을 사용하고 있습니다.
web.php 파일 내의 애플리케이션에서 이전에 경로를 정의하여 각 경로에 대해 기억하기 쉬운 이름을 지정했다는 것을 기억하십시오. {{route()}} 지시문은 경로 이름을 받아들이고, 내부적으로 캐시된 경로 목록 내에서 이를 조회하고, web.php 파일에 있는 해당 경로의 정의를 기반으로 전체 URL을 생성합니다. 첫 번째 경우에는 양식이 제출된 데이터를 애플리케이션의 /process URL로 보내도록 지정합니다. POST 경로.
다음으로 눈에 띄는 이상한 점은 여는 양식 태그 바로 아래에 있는 @csrf 태그입니다. 블레이드에서 이 태그는 양식 데이터가 처리되기 전에 애플리케이션 내부에서 확인되는 _token 매개변수를 양식에 생성합니다. 이렇게 하면 양식 내부의 데이터가 유효한 원본인지 확인하고 사이트 간 요청 위조 공격을 방지할 수 있습니다. 이에 대한 자세한 내용은 다음을 참조하세요. 문서.
그런 다음 양식을 정상적으로 정의합니다. 그러나 양식 매개변수인 userFile 및 fileName의 이름은 다음과 같습니다. 같은 정확한 요청 객체 내부에 정의된 대로입니다. 요청 개체에 정의된 특정 매개 변수에 대한 입력을 포함하는 것을 잊은 경우(또는 철자가 틀린 경우) 요청이 실패하고 오류가 반환되어 원래 양식 요청이 UploadController@에 있는 컨트롤러 메서드에 도달하지 못하게 됩니다. 프로세스 .
계속해서 시험해보고 이 양식을 사용하여 몇 가지 파일을 신청서에 제출하십시오. 그런 다음 /목록 업로드한 파일이 표에 나열되어 있는 업로드 폴더의 내용을 보려면 다음 페이지를 참조하세요.
더 큰 그림
한 걸음 물러서서 이 Laravel 튜토리얼에서 우리가 수행한 작업을 살펴보겠습니다.
이 다이어그램은 현재 상태의 애플리케이션을 보여줍니다(상위 수준의 세부 정보는 제외).
이 Laravel 튜토리얼의 시작 부분에서 생성한 요청 개체에는 블레이드 템플릿의 양식에 있는 것과 동일한 규칙 메서드에 정의된 매개 변수가 있어야 한다는 점을 기억해야 합니다("검증 논리 생성" 섹션을 다시 읽지 않은 경우). . 사용자는 블레이드 템플릿 엔진을 통해 렌더링되는 웹 페이지에 양식을 입력하고(이 프로세스는 물론 자동 파일럿이므로 생각할 필요도 없습니다) 양식을 제출합니다. 하단에 있는 템플릿의 jQuery 코드는 기본 제출(자동으로 별도의 페이지로 리디렉션됨)을 중지하고, ajax 요청을 생성하고, 양식 데이터와 함께 요청을 로드하고 파일을 업로드한 다음 모든 것을 우리의 첫 번째 레이어로 보냅니다. 신청: 요청.
요청 객체는 규칙() 메서드 내부의 매개변수를 제출된 양식 매개변수와 연결하여 채워진 다음 지정된 각 규칙에 따라 데이터의 유효성을 검사합니다. 모든 규칙이 충족되면 요청은 경로 파일 web.php에 정의된 값에 해당하는 컨트롤러 메서드로 전달됩니다. 이 경우 작업을 수행하는 것은 UploadController의 process() 메서드입니다. 컨트롤러에 도달하면 요청이 유효성 검사를 통과했다는 것을 이미 알고 있으므로 주어진 파일 이름이 실제로 문자열인지 또는 userFile 매개 변수가 실제로 어떤 유형의 파일을 보유하고 있는지 다시 테스트할 필요가 없습니다. 다음과 같이 계속할 수 있습니다. 정상.
그런 다음 컨트롤러 메서드는 요청 객체에서 검증된 매개변수를 가져오고, 전달된 fileName 매개변수를 userFile의 원래 확장자와 연결하여 전체 파일 이름을 생성하고, 해당 파일을 애플리케이션의 디렉터리 내에 저장한 다음 간단한 JSON 인코딩을 반환합니다. 요청이 성공했음을 확인하는 응답입니다. 응답은 jQuery 로직에 의해 수신됩니다. 이 로직은 성공(또는 오류) 메시지를 5초 동안 표시한 후 숨기고 이전 양식 항목을 지우는 등 몇 가지 UI 관련 작업을 더 수행합니다. 이는 사용자가 알 수 있습니다. 요청이 성공했는지 확인하고 원하는 경우 다른 파일을 업로드할 수 있습니다.
또한, 위의 다이어그램에서 클라이언트와 서버 사이에 선이 그어진 곳을 주목하세요. 이 개념은 여러분이 이해하는 데 절대적으로 중요하며, 예를 들어 주어진 시간에 발생할 수 있는 여러 비동기 요청을 처리할 때 미래에 발생할 수 있는 문제와 이슈를 해결하는 데 도움이 될 것입니다. 분리는 요청 객체의 경계에 바로 있습니다. 요청 객체 자체는 나머지 애플리케이션에 대한 "게이트웨이"로 생각할 수 있습니다... 웹 브라우저에서 전달된 양식 값의 초기 유효성 검사 및 등록을 수행합니다. 유효한 것으로 간주되면 컨트롤러로 계속 진행됩니다. 그 이전의 모든 것은 프런트 엔드에 있습니다("클라이언트"는 문자 그대로 "사용자의 컴퓨터"를 의미합니다). 응답은 앱에서 클라이언트 측으로 반환되고, jQuery 코드는 응답이 도착할 때까지 인내심을 가지고 기다리고 응답을 받으면 몇 가지 간단한 UI 작업을 수행합니다.
우리는 자주 묻는 거의 90개 이상의 중요 사항을 다뤘습니다. Laravel 및 PHP 관련 인터뷰 질문 신입뿐만 아니라 경력 지원자도 올바른 직업을 얻을 수 있습니다.