Development

Changeset 8338

You must first sign up to be able to contribute.

Changeset 8338

Show
Ignore:
Timestamp:
04/07/08 07:37:08 (6 months ago)
Author:
dwhittle
Message:

1.1: updated docs for bridges and autoloading

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • doc/branches/1.1/book/17-Extending-Symfony.txt

    r8337 r8338  
    473473        class: myRequest 
    474474 
    475 Bridges to Other Framework's Components 
    476 --------------------------------------- 
    477  
    478 If you need capabilities provided by a third-party class, and if you don't want to copy this class in one of the symfony `lib/` dirs, you will probably install it outside of the usual places where symfony looks for files. In that case, using this class will imply a manual `require` in your code, unless you use the symfony bridge to take advantage of the autoloading. 
     475Integrating with Other Framework's Components 
     476--------------------------------------------- 
     477 
     478If you need capabilities provided by a third-party class, and if you don't want to copy this class in one of the symfony `lib/` dirs, you will probably install it outside of the usual places where symfony looks for files. In that case, using this class will imply a manual `require` in your code, unless you use the symfony spl autoload integration to take advantage of the autoloading. 
    479479 
    480480Symfony doesn't (yet) provide tools for everything. If you need a PDF generator, an API to Google Maps, or a PHP implementation of the Lucene search engine, you will probably need a few libraries from the Zend Framework. If you want to manipulate images directly in PHP, connect to a POP3 account to read e-mails, or design a console interface, you might choose the libraries from eZcomponents. Fortunately, if you define the right settings, the components from both these libraries will work out of the box in symfony. 
    …… 
    485485      zend_lib_dir:   /usr/local/zend/library/ 
    486486      ez_lib_dir:     /usr/local/ezcomponents/ 
    487  
    488 Then, extend the PHP autoload system by specifying which library to consider when the autoloading fails with symfony. You can do this by registering symfony bridge classes in the application `config.php` file (see Chapter 19 for more information): 
    489  
    490     [php] 
    491     spl_autoload_register(array('sfZendFrameworkBridge', 'autoload')); 
    492     spl_autoload_register(array('sfEzComponentsBridge', 'autoload')); 
     487      swift_lib_dir:  /usr/local/swiftmailer/ 
     488 
     489Then, extend the PHP autoload system by specifying which library to consider when the autoloading fails with symfony. You can do this by registering the autoload classes in the application configuration class (see Chapter 19 for more information): 
     490 
     491    [php] 
     492    class frontendConfiguration extends sfApplicationConfiguration 
     493    { 
     494      public function initialize() 
     495      { 
     496        parent::initialize(); // load symfony autoloading first 
     497 
     498        // Integrate Zend Framework 
     499        if($sf_zend_lib_dir = sfConfig::get('sf_zend_lib_dir')) 
     500        { 
     501          set_include_path($sf_zend_lib_dir.PATH_SEPARATOR.get_include_path()); 
     502 
     503          require_once($sf_zend_lib_dir.'/Zend/Loader.php'); 
     504          spl_autoload_register(array('Zend_Loader', 'Zend_Loader')); 
     505        } 
     506 
     507        // Integrate eZ Components 
     508        if($sf_ez_lib_dir = sfConfig::get('sf_ez_lib_dir')) 
     509        { 
     510          set_include_path($sf_ez_lib_dir.PATH_SEPARATOR.get_include_path()); 
     511 
     512          require_once($sf_ez_lib_dir.'/Base/base.php'); 
     513          spl_autoload_register(array('ezcBase', 'autoload')); 
     514        } 
     515 
     516        // Integrate Swift Mailer 
     517        if($sf_swift_lib_dir = sfConfig::get('sf_swift_lib_dir')) 
     518        { 
     519          set_include_path($sf_swift_lib_dir.PATH_SEPARATOR.get_include_path()); 
     520 
     521          require_once($sf_swift_lib_dir.'/Swift/ClassLoader.php'); 
     522          spl_autoload_register(array('Swift_ClassLoader', 'load')); 
     523        } 
     524      } 
     525    } 
    493526 
    494527The following describes what will happen when you create a new object of an unloaded class: 
    495528 
    496529  1. The symfony autoloading function (`sfAutoload::autoload()`) first looks for a class in the paths declared in the `autoload.yml` file. 
    497   2. If none is found, the callback methods registered by `spl_autoload_register()` calls will be called one after the other, until one of them returns `true`: 
    498   3. `sfZendFrameworkBridge::autoload()` 
    499   4. `sfEzComponentsBridge::autoload()` 
    500   5. If these also return `false`, PHP will generate an error. 
     530  2. If no class path is found, the callback methods registered by `spl_autoload_register()` calls will be called one after the other, until one of them returns `true`: 
     531  3. `Zend_Loader::Zend_Loader()` 
     532  4. `ezcBase::autoload()` 
     533  5. `Swift_ClassLoader::load()` 
     534  6. If these also return `false`, PHP will generate an error. 
    501535 
    502536This means that the other framework components benefit from the autoload mechanism, and you can use them even more easily than within their own environment. For instance, if you want to use the `Zend_Search` component in the Zend Framework to implement an equivalent of the Lucene search engine in PHP, you have to write this: 
    …… 
    508542    ... 
    509543 
    510 With symfony and the Zend Framework bridge, it is simpler. Just write this: 
     544With symfony and spl autoloading, it is simpler. Just write this with out any need for require: 
    511545 
    512546    [php] 
    …… 
    515549    ... 
    516550 
    517 The available bridges are stored in the `$sf_symfony_lib_dir/addon/bridge/` directory. 
    518  
    519551Plug-Ins 
    520552-------- 
    …… 
    536568Some of these plug-ins are contributions from the community, and some come from the core symfony developers. Among the latter, you will find the following: 
    537569 
    538   * `sfFeedPlugin`: Automates the manipulation of RSS and Atom feeds 
     570  * `sfFeed2Plugin`: Automates the manipulation of RSS and Atom feeds 
    539571  * `sfThumbnailPlugin`: Creates thumbnails--for instance, for uploaded images 
    540572  * `sfMediaLibraryPlugin`: Allows media upload and management, including an extension for rich text editors to allow authoring of images inside rich text 

  • doc/branches/1.1/book/19-Mastering-Symfony-s-Configuration-Files.txt

    r8337 r8338  
    268268A rule path can contain wildcards and use the file path parameters from the `constants.php` file (see the next section). If you use these parameters in the configuration file, they must appear in uppercase and begin and end with `%`. 
    269269 
    270 Editing your own `autoload.yml` will add new locations to symfony's autoloading, but you may want to extend this mechanism and add your own autoloading handler to symfony's handler. As symfony uses the standard `spl_autoload_register()` function to manage class autoloading, you can register more callbacks in the application `config.php` file: 
    271  
    272     [php] 
    273     // include project configuration 
    274     include(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php'); 
    275  
    276     // symfony bootstraping 
    277     require_once($sf_symfony_lib_dir.'/util/sfCore.class.php'); 
    278     sfCore::bootstrap($sf_symfony_lib_dir, $sf_symfony_data_dir); 
    279  
    280     // insert your own autoloading callables here 
    281     spl_autoload_register(array('myToolkit', 'autoload')); 
    282  
    283     if (sfConfig::get('sf_debug')) 
     270Editing your own `autoload.yml` will add new locations to symfony's autoloading, but you may want to extend this mechanism and add your own autoloading handler to symfony's handler. As symfony uses the standard `spl_autoload_register()` function to manage class autoloading, you can register more callbacks in the application configuration class: 
     271 
     272    [php] 
     273    class frontendConfiguration extends sfApplicationConfiguration 
    284274    { 
    285       spl_autoload_register(array('sfAutoload', 'autoloadAgain')); 
     275      public function initialize() 
     276      { 
     277        parent::initialize(); // load symfony autoloading first 
     278 
     279        // insert your own autoloading callables here 
     280        spl_autoload_register(array('myToolkit', 'autoload')); 
     281      } 
    286282    } 
     283 
    287284 
    288285When the PHP autoloading system encounters a new class, it will first try the symfony autoloading method (and use the locations defined in `autoload.yml`). If it doesn't find a class definition, all the other callables registered with `spl_autoload_register()` will be called, until the class is found. So you can add as many autoloading mechanisms as you want--for instance, to provide a bridge to other framework components (see Chapter 17).