HttpKernel 組件

HttpKernel：由事件驅動

HttpKernel::handle() 方法透過分發事件在內部運作。這使得該方法既靈活又有點抽象，因為使用 HttpKernel 建置的框架/應用程式的所有「工作」實際上都是在事件監聽器中完成的。

為了幫助解釋這個過程，本文將著眼於過程的每個步驟，並討論 HttpKernel 的一個特定實作 - Symfony 框架 - 如何運作。

最初，使用 HttpKernel 不需要太多步驟。您建立一個事件分發器和一個控制器和參數解析器（如下所述）。為了完成您的運作核心，您將為下面討論的事件新增更多事件監聽器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

use Symfony\Component\EventDispatcher\EventDispatcher;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\HttpKernel\Controller\ArgumentResolver;
use Symfony\Component\HttpKernel\Controller\ControllerResolver;
use Symfony\Component\HttpKernel\HttpKernel;

// create the Request object
$request = Request::createFromGlobals();

$dispatcher = new EventDispatcher();
// ... add some event listeners

// create your controller and argument resolvers
$controllerResolver = new ControllerResolver();
$argumentResolver = new ArgumentResolver();

// instantiate the kernel
$kernel = new HttpKernel($dispatcher, $controllerResolver, new RequestStack(), $argumentResolver);

// actually execute the kernel, which turns the request into a response
// by dispatching events, calling a controller, and returning the response
$response = $kernel->handle($request);

// send the headers and echo the content
$response->send();

// trigger the kernel.terminate event
$kernel->terminate($request, $response);

請參閱「完整的運作範例」以取得更具體的實作。

有關將監聽器新增至以下事件的一般資訊，請參閱建立事件監聽器。

1) kernel.request 事件

典型用途：向 Request 新增更多資訊、初始化系統的各個部分，或在可能時傳回 Response（例如，拒絕存取的安全性層）。

核心事件資訊表

在 HttpKernel::handle 內部分發的第一個事件是 kernel.request，它可能具有各種不同的監聽器。

此事件的監聽器可能非常多樣化。某些監聽器（例如安全性監聽器）可能具有足夠的資訊來立即建立 Response 物件。例如，如果安全性監聽器判斷使用者沒有存取權，則該監聽器可能會傳回 RedirectResponse 至登入頁面或 403 拒絕存取回應。

如果在此階段傳回 Response，則程序將直接跳至 kernel.response 事件。

其他監聽器會初始化事物或向請求新增更多資訊。例如，監聽器可能會判斷並在 Request 物件上設定語言環境。

另一個常見的監聽器是路由。路由器監聽器可能會處理 Request 並判斷應呈現的控制器（請參閱下一節）。實際上，Request 物件具有「屬性」包，這是儲存有關請求的額外應用程式特定資料的完美位置。這表示如果您的路由器監聽器以某種方式判斷控制器，則它可以將其儲存在 Request 屬性上（您的控制器解析器可以使用它）。

總體而言，kernel.request 事件的目的是直接建立並傳回 Response，或向 Request 新增資訊（例如設定語言環境或在 Request 屬性上設定其他資訊）。

2) 解析控制器

假設沒有 kernel.request 監聽器能夠建立 Response，則 HttpKernel 中的下一步是判斷和準備（即解析）控制器。控制器是最終應用程式程式碼的一部分，負責為特定頁面建立和傳回 Response。唯一的要求是它是 PHP 可呼叫物件 - 即函式、物件上的方法或 Closure。

但是，如何判斷請求的確切控制器完全取決於您的應用程式。這是「控制器解析器」的工作 - 一個實作 ControllerResolverInterface 的類別，並且是 HttpKernel 的建構函式引數之一。

您的工作是建立一個實作介面的類別，並填寫其方法：getController()。實際上，已經存在一個預設實作，您可以直接使用或從中學習：ControllerResolver。此實作在下面的側邊欄中進行了更多說明

1
2
3
4
5
6
7
8

namespace Symfony\Component\HttpKernel\Controller;

use Symfony\Component\HttpFoundation\Request;

interface ControllerResolverInterface
{
    public function getController(Request $request): callable|false;
}

在內部，HttpKernel::handle() 方法首先在控制器解析器上呼叫 getController()。此方法會傳遞 Request，並負責以某種方式根據請求的資訊判斷並傳回 PHP 可呼叫物件（控制器）。

3) kernel.controller 事件

典型用途：初始化事物或在控制器執行之前變更控制器。

核心事件資訊表

在判斷控制器可呼叫物件後，HttpKernel::handle() 會分發 kernel.controller 事件。此事件的監聽器可能會初始化系統的某些部分，這些部分需要在某些事物（例如控制器、路由資訊）已判斷但控制器尚未執行之後初始化。

此事件的另一個典型用例是使用 getAttributes() 方法從控制器擷取屬性。有關一些範例，請參閱下面的 Symfony 區段。

此事件的監聽器也可以透過在傳遞給此事件監聽器的事件物件上呼叫 ControllerEvent::setController 來完全變更控制器可呼叫物件。

4) 取得控制器參數

接下來，HttpKernel::handle() 呼叫 ArgumentResolverInterface::getArguments()。請記住，在 getController() 中傳回的控制器是可呼叫物件。getArguments() 的目的是傳回應傳遞給該控制器的引數陣列。雖然內建的 ArgumentResolver 是一個很好的範例，但確切的做法完全取決於您的設計。

此時，核心具有 PHP 可呼叫物件（控制器）和在執行該可呼叫物件時應傳遞的引數陣列。

5) 呼叫控制器

HttpKernel::handle() 的下一步是執行控制器。

控制器的職責是為給定的資源建置回應。這可以是 HTML 頁面、JSON 字串或任何其他內容。與到目前為止程序的每個其他部分不同，此步驟由「最終開發人員」針對建置的每個頁面實作。

通常，控制器會回傳一個 Response 物件。如果這是真的，那麼 Kernel 的工作就差不多完成了！在這種情況下，下一步是 kernel.response 事件。

但是，如果控制器回傳的不是 Response，那麼 Kernel 還有更多工作要做 - kernel.view (因為最終目標是始終產生一個 Response 物件)。

6) kernel.view 事件

典型用途：將來自控制器的非 Response 回傳值轉換為 Response

核心事件資訊表

如果控制器沒有回傳 Response 物件，那麼 Kernel 會分派另一個事件 - kernel.view。此事件的監聽器的工作是使用控制器的回傳值（例如，資料陣列或物件）來建立一個 Response。

如果您想使用「視圖」層，這會很有用：您可以從控制器回傳代表頁面的資料，而不是回傳 Response。此事件的監聽器接著可以使用這些資料來建立格式正確的 Response（例如 HTML、JSON 等）。

在這個階段，如果沒有監聽器在此事件上設定回應，則會拋出例外：控制器或其中一個視圖監聽器必須始終回傳 Response。

7) kernel.response 事件

典型用途：在 Response 物件傳送之前修改它

核心事件資訊表

Kernel 的最終目標是將 Request 轉換為 Response。Response 可能在 kernel.request 事件期間建立，從 控制器 回傳，或由 kernel.view 事件的監聽器之一回傳。

無論誰建立 Response，另一個事件 - kernel.response 會在之後立即分派。此事件的典型監聽器將以某種方式修改 Response 物件，例如修改標頭、新增 Cookie，甚至變更 Response 本身的內容（例如，在 HTML 回應的結尾 </body> 標籤之前注入一些 JavaScript）。

在此事件分派之後，最終的 Response 物件會從 handle() 回傳。在最典型的用例中，您可以接著呼叫 send() 方法，該方法會傳送標頭並印出 Response 內容。

8) kernel.terminate 事件

典型用途：在回應串流傳輸到使用者後執行一些「繁重」的操作

核心事件資訊表

HttpKernel 流程的最後一個事件是 kernel.terminate，它是獨特的，因為它發生在 HttpKernel::handle() 方法之後，以及在回應傳送給使用者之後。回想一下上面的內容，然後使用 Kernel 的程式碼會像這樣結束

1
2
3
4
5

// sends the headers and echoes the content
$response->send();

// triggers the kernel.terminate event
$kernel->terminate($request, $response);

如您所見，透過在傳送回應後呼叫 $kernel->terminate，您將觸發 kernel.terminate 事件，您可以在其中執行某些您可能延遲的操作，以便盡快將回應回傳給用戶端（例如，傳送電子郵件）。

9) 處理例外：kernel.exception 事件

典型用途：處理某些類型的例外，並建立適當的 Response 以針對例外回傳

核心事件資訊表

如果在 HttpKernel::handle() 內部任何時間點拋出例外，則會分派另一個事件 - kernel.exception。在內部，handle() 方法的主體被包裝在 try-catch 區塊中。當拋出任何例外時，會分派 kernel.exception 事件，以便您的系統可以以某種方式回應例外。

此事件的每個監聽器都會傳遞一個 ExceptionEvent 物件，您可以使用它透過 getThrowable() 方法存取原始例外。此事件上的典型監聽器將檢查特定類型的例外，並建立適當的錯誤 Response。

例如，為了產生 404 頁面，您可能會拋出特殊類型的例外，然後在此事件上新增一個監聽器，該監聽器會尋找此例外，並建立及回傳 404 Response。事實上，HttpKernel 元件帶有一個 ErrorListener，如果您選擇使用它，預設情況下會執行此操作以及更多操作（請參閱下面的側邊欄以取得更多詳細資訊）。

ExceptionEvent 公開了 isKernelTerminating() 方法，您可以使用它來判斷 Kernel 在拋出例外時是否正在終止。