Symfony2 学习笔记之内部构件

标签：blog   http   使用   os   io   strong   文件   数据   

Symfony2内部是怎样工作的以及我们如何来扩展它呢？
从外部整体上看，symfony2代码是由许多独立的层构成，每一层都是建立在前一层基础之上。其中，自动加载时不受框架直接管理的，它完全是在UniversalClassLoader类和src/autoload.php文件的帮助下独立完成的。

HttpFoundation 组件
最深层次的是HttpFoundation组件，它提供了处理HTTP所需的主要对象。是一个对一些PHP函数和变量的面向对象抽象。
包括：
Request 类，抽象了PHP中主要的全局变量$_GET,$_POST,$_COOKIE,$_FILES 和 $_SERVER。
Response类，抽象类一些PHP函数比如header(), setcookie()和echo();
Session 类和SessionStorageInterface接口则是抽象了Session管理Session_*()函数。

HttpKernel 组件：
在HttpFoundation组件之上创建的一个组件，它处理HTTP的动态部分。它是为了能够通过标准的方式来处理request,而对Request和Response对象的一个最小封装。同时它提供了一些扩展点和工具，让它成为创建一个web框架的最理想的开始点。

另外，Dependency Injection组件和强大的插件系统bundles让它增加了可配置性和扩展性。

FrameworkBundle Bundle
FrameworkBundle bundle 是一个bundle，它是构成轻量级快速MVC框架的主要组件和类库。

Kernel
HttpKernel类是Symfony2的中心类，它负责处理客户端请求。它的主要任务就是把Request对象转换成Response对象。每个Symfony2核心实现HttpKernelInterface接口。

function handle(Request $request,$type=self::MASTER_REQUEST,$catch=true)

Controller
Kernel依靠Controller来吧Request转换为Response。 Controller可以是任何有效的PHP调用。Kernel委托选择哪个Controller应该被执行给一个ControllerResolverInterface接口的实现者。

public function getController(Request $request);
public function getArguments(Request $request,$controller);

其中，getController()方法返回一个和给定的Request相对于的Controller（一个PHP调用）。ControllerResolver的默认实现是查找Request的一个_controller属性，它的值是一个class::method 格式的字符串。比如Bundle\BlogBundle\PostController::indexAction 。默认的实现使用RouterListener来定义Request的属性 _controller。getArguments()方法返回一个输入参数数组来传递给Controller调用。默认实现会根据Request属性自动的获取这些输入参数。

从Request属性中匹配Controller方法的输入参数：Symfony2对于每一个方法的输入参数都会是这从Request中查找其同名属性，如果没有定义，就会取该输入参数的默认值。

// Symfony2 从Request属性中查找 ‘id‘ 属性（强制）
// 和一个‘admin‘ 属性 (可选)
public function showAction($id, $admin = true)
{
       // ...
}

处理请求：handle()方法需要一个Request参数并且永远都必须返回一个Response。要转换Request，handle()需要依靠一个分析器和一个事件通知顺序链。
1. 在处理任何事情之前，kernel.request事件将被通知 --如果一个监听者返回了一个Response，那么它会直接跳至第8步。
2. 分析器被调用来判断哪个Controller将被执行。
3. kernel.controller事件监听器现在开始处理Controller调用（改变它，封装它...)
4. Kernel检查Controller是否是一个合法可调用的PHP回调。
5. 分析器被调用来决定传递给controller的参数
6. Kernel调用Controller
7. 如果Controller没有返回Response对象，kernel.view事件监听器会把Controller的返回值转换成一个Response。
8. kernel.response事件监听器开始处理Response（内容和头部）;
9. Response对象被返回。

如果在这个过程中有一个异常被抛出，kernel.exception就会被通知，监听器就把异常转换为一个Response，之后kernel.response事件就会被通知，如果没能转换，该异常就会被抛出。

如果你不想异常被捕获，你可以通过传递一个false作为第三个参数到handle()方法，来关闭kernel.exception事件。

内部请求
在处理一个主请求的任何时候，子请求都可以被处理。你可以传递一个请求类型到handle()方法，作为它的第二个参数。

HttpKernelInterface::MASTER_ReQUEST;
HttpKernelInterface::SUB_REQUEST

这些类型会根据需要传递给所有的事件和监听器。

事件
Kernel抛出的每一个事件都会是KernelEvent类的子类。这就意味着每个事件都可以访问相同的基础信息。
getRequestType() 返回请求的类型（HttpKernelInterface::MASTER_REQUEST 或者 HttpKernelInterface::SUB_REQUEST;
getKernel() 返回处理请求的Kernel
getRequest() 返回一个当前被处理的请求

getRequestType()方法允许监听器知道请求的类型。比如，如果一个监听器必须是主请求才能激活它，你可以把该代码添加到你监听器方法的开头：

use Symfony\Component\HttpKernel\HttpKernelInterface;
if(HttpKernelInterface::MASTER_REQUEST !== $event->getRequestType()){
      //立刻返回
      return;
}

kernel.request 事件
事件类：GetResponseEvent

该事件的目标是立刻返回一个Response对象或者创建一个在事件结束后Controller可以调用的变量。任何监听器都可以通过event的setResponse()方法返回一个Response对象，当有Response对象被返回时，其它的监听器就不能在被调用了。

FrameworkBundle使用事件通过RouterListener来发布一个_controller 请求属性。
RequestListener 使用一个RouterInterface对象匹配Request，决定哪个Controller的名字会被存储到_controller的请求属性里。

kernel.controller 事件：
事件类： FilterControllerEvent

FrameworkBundle不会使用该事件，但是该事件可以被作为一个修改要执行的controller的一个入口点。

use Symfony\Component\Httpkernel\Event\FilterControllerEvent;

public function onKernelController(FilterControllerEvent $event)
{
        $controller = $event->getController();
         //...

        // 此处controller可以被该换成任何PHP可回调函数
        $event->setController($controller);
}

kernel.view 事件
事件类：GetResponseForControllerResultEvent

FrameworkBundle也不会使用该事件，但是它被用来实现一个视图子系统。该事件只有当Controller不能返回一个Response对象时才被调用。它的目的就是把其他类型的返回值转换成一个Response。

Controller的返回值可以通过getControllerResult方法访问：

use Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent;
use Symfony\Component\HttpFoundation\Response;

public function onKernelView(GetResponseForControllerResultEvent $event)
{
        $val = $event->getControllerResult();
        $response = new Response();
        //通过返回值自定义化Response
        $event->setResponse($response);
}

kernel.response 事件
事件类：FilterResponseEvent

该事件的目的是允许其它系统在Response对象被创建后对它进行修改或者替换。

public function onKernelResponse(FilterResponseEvent $event)
{
       $response = $event->getResponse();
       //修改Response对象
}

FrameworkBundle注册了许多的监听器：

        ProfilerListener 从当前请求中搜集数据
        WebDebugToolbarListener 注入Web 调试工具条
        ResponseListener 基于请求的格式来为Response设置Content-type
        EsiListener 当Response需要解析ESI标签时，向其添加一个Surrogate-Control HTTP头。

kernel.exception 事件：
事件类：GetResponseForExceptionEvent
     FrameworkBundle注册一个ExceptionListener把请求定向到一个给定Contoller。这个事件的监听器可以创建和设置一个Response对象，创建设置一个新的Exception对象或者什么都不做。

use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
use Symfony\Component\HttpFoundation\Response;

public function onKernelException(GetResponseForExceptionEvent $event)
{
        $exception = $event->getException();
        $response = new Response();
        // 基于捕获的异常创建一个Response对象
        $event->setResponse($response);

        // 你可以创建一个新的异常代替原有的
        // $exception = new \Exception(‘Some special exception‘);
        // $event->setException($exception);
}

总结思考：我们了解了Symfony2内部的主要部件和一些主要的事件接口，我们可以在各个事件接口定义相应的监听器处理，来对请求处理过程进行干预操作。

参考URL：http://symfony.com/doc/current/book/internals.html

Symfony2 学习笔记之内部构件,布布扣,bubuko.com

Symfony2 学习笔记之内部构件

标签：blog   http   使用   os   io   strong   文件   数据   

原文地址：http://www.cnblogs.com/huidaoli/p/3894470.html