1. 自由主题
2. app.yml 与 setting.yml 的差别是什么
3. 基本都是截取原文，但我把思路和文中阐述的层次关系缕顺出来了
4. Bootstrap 启动流程
   1. web/frontend_dev.php 这是 前台的 controller
      1. 一共两行代码
      2. $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', true);
         1. allowing you to pass a custom root directory for your application as the fourth argument of ProjectConfiguration::getApplicationConfiguration()
      3. sfContext::createInstance($configuration)->dispatch();
         1. a custom context class as the third (and last) argument of sfContext::createInstance()
         2. but remember it has to extend sfContext
   2. sfProjectConfiguration 基类
      1. ProjectConfiguration
         1. 继承 sfProjectConfiguarationi
         2. This is fortunate since much of the project is configured inside the sfProjectConfiguration constructor
            1. several useful values are computed and stored, such as the project’s root directory and the symfony library directory.
            2. sfProjectConfiguration also creates a new event dispatcher of type sfEventDispatcher
            3. 当然，除非在 front controller 里预先设置好 ProjectConfiguration::getApplicationConfiguration() 的第五个参数
            4. 比如 enable 和 disable 各个 plugin
            5. by using sfProjectConfiguration::setPlugins()
            6. 接下来 plugins are loaded by sfProjectConfiguration ::loadPlugins()
            7. the developer has a chance to interact with this process through the sfProjectConfiguration::setupPlugins() that can be overriden
            8. Plugin initialization is quite straight forward. For each plugin, symfony looks for a ${plugin}Configuration (e.g. sfGuardPluginConfiguration) class and instantiates it if found. Otherwise, sfPluginConfigurationGeneric is used.
            9. You can hook into a plugin’s configuration through two methods
            10. ${plugin}Configuration::configure(), before autoloading is done
            11. ${plugin}Configuration::initialize(), after autoloading
            12. sfSocialPlugin 中的 listener，在这里hook 一下，以便监听
            13. 接下来, sfApplicationConfiguration 执行插件的 configure()
            14. 这可以在sfApplicationConfiguration::initConfiguration() 之前更改application’s configuration
            15. 这里有好几个入口点 可以挂钩 hook
            16. For example, you can interact with the autoloader’s configuration by connecting to the autoload.filter_config event
            17. Next,several very important configuration files are loaded, including settings.yml and app.yml
            18. Finally, a last bit of plugin configuration is available through each plugin’s config/config.php file or configuration class’s initialize() method
            19. If sf_check_lock is activated
            20. symfony will now check for a lock file (the one created by the project:disable task, for example
            21. f the lock is found, the following files are checked and the first available is included, followed immediately by termination of the script
            22. apps/${application}/config/unavailable.php
            23. config/unavailable.php
            24. web/errors/unavailable.php
            25. lib/vendor/symfony/lib/exception/data/unavailable.php
            26. Finally, the developer has one last chance to customize the application’s initialization through the sfApplicationConfiguration::initialize() method
      2. 每个app
         1. 每个 app 都有自己的 configuaration
         2. apps/${application}/config/${application}Configuration.class.php
         3. sfApplicationConfiguration actually extends ProjectConfiguration
         4. 接着 frontendConfiguration extends sfApplicationConfiguration
            1. meaning that any method in ProjectConfiguration can be shared between all applications
   3. 整个流程
      1. 1:: ProjectConfiguration::setup() (define your plugins here) 1:: Plugins are loaded 1:: ${plugin}Configuration::configure() 1:: ${plugin}Configuration::initialize() 1:: ProjectConfiguration::setupPlugins() (setup your plugins here) 1:: ${application}Configuration::configure() 1:: autoload.filter_config is notified 1:: Loading of settings.yml and app.yml 1:: ${application}Configuration::initialize()
5. sfContext and Factories
   1. factories.yml
      1. 每个程序只能 有一个实例的 放在这里
         1. response
         2. mailer
         3. user
         4. routing
         5. view_cache_manager
   2. 工厂模式
   3. factories are a set of components or classes that your application relies on.
   4. Each factory is configured via factories.yml
      1. factories.yml is compiled by a config handler (more on config handlers later) and converted into PHP code that actually instantiates the factory objects
      2. you can view this code in your cache in the cache/frontend/dev/config/config_factories.yml.php file
   5. Factory loading happens upon sfContext initialization. sfContext::initialize() and sfContext::loadFactories() for information.
   6. 在cache/frontend/dev/config/config_factories.yml.php 里 各种factory 的初始化都是有顺序的，那是因为某些工厂会依赖其他
      1. 比如the routing component obviously needs the request to retrieve the information it needs
         1. 没明白，可能还是对 routing的机理不是很清楚
   7. request
      1. By default, the sfWebRequest class represents the request
      2. Upon instantiation, sfWebRequest::initialize()81 is called, which gathers relevant information::
         1. the GET / POST parameters
         2. the HTTP method
      3. You’re then given an opportunity to add your own request processing through the request.filter_parameters event
      4. 《more with symfony》P131
   8. routing
      1. You can hook up to this process through the routing.load_configuration event
      2. routing.load_configuration event gives you access to the current routing object’s instance (by default, sfPatternRouting
      3. 类似 sfForkApplyPlugin 里做的一样
   9. Once all factories have been loaded and properly setup, the context.load_factories event is triggered
      1. it’s the earliest event in the framework
      2. This is also the time to connect to another very useful event: template.filter_parameters
         1. This event occurs whenever a file is rendered by sfPHPView
         2. and allows the developer to control the parameters actually passed to the template.
      3. sfContext takes advantage of this event to add some useful parameters to each template
         1. $sf_context
         2. $sf_request
         3. $sf_params
         4. $sf_response
         5. $sf_user
      4. 所以可以通过template.filter_parameters event 来给特定template 一个全局变量
         1. 例子 在书中P134
   10. sfContext
       1. 1. Initialization of sfContext 2. Factory loading 3. Events notified: 1. request.filter_parameters 2. routing.load_configuration 3. context.load_factories 4. Global templates parameters added
6. config handlers
   1. 是 symfony’s configuration system 的核心
   2. Each config handler is simply a class that is used to translate a set of yaml configuration files into a block of PHP code that can be executed as needed
   3. Each configuration file is assigned to one specific config handler in the config_handlers.yml file
      1. http://trac.symfony-project.org/browser/branches/1.3/lib/config/ config/config_handlers.yml
   4. the job of a config handler is not to actually parse the yaml files (this is handled by sfYaml)
   5. Instead each config handler creates a set of PHP directions based on the YAML information and saves those directions to a PHP file which can be efficiently included later
   6. The compiled version of each YAML configuration file can be found in the cache directory.
7. The Dispatching andExecution of the Request
   1. Once sfContext is finished initializing, the final step is to call the controller’s dispatch() method, sfFrontWebController::dispatch()
   2. In fact, sfFrontWebController::dispatch() simply pulls the module and action names from the request parameters and forwards the application via sfController::forward()
      1. The forward method is responsible for a lot of pre-execution checks as well as preparing the configuration and data for the action to be executed
   3. parse any module name or action name from the current url, an sfError404Exception94 is raised