Commit Graph

24 Commits

Author SHA1 Message Date
Fabien Potencier
7fc174b0ad [TwigBundle] added a Twig runtime loader 2016-09-29 13:59:59 -07:00
Jean-François Simon
e372183b26 [TwigBundle] Adds service check for extension loading 2013-03-14 12:28:51 +01:00
dantleech
f48b22a44e Added configuration pass that adds Twig Loaders
- Added compiler class which picks up any services tagged "twig.loader"
- If there is one loader registered we set the alias to this loader
- If there is more than one we set the alias to a chain loader and all
  the loaders to it
- If there is no loaders we throw an Exception
2012-12-07 17:39:55 +01:00
Fabien Potencier
3749ad43f4 moved the Exception listener from FrameworkBundle to TwigBundle as it relies on Twig being enabled
This commit also fixes exception pages when Twig is not enabled as a templating engine.
Instead of just displaying the raw Twig template as before, we now fallback to the default
exception handler introduced some time ago.
2011-07-21 19:24:04 +02:00
Fabien Potencier
8c423edfef replaced symfony-project.org by symfony.com 2011-03-06 12:40:06 +01:00
Fabien Potencier
14aa95ba21 added the concept of a main DIC extension for bundles
This allows for better conventions and better error messages if you
use the wrong configuration alias in a config file.

This is also the first step for a bigger refactoring of how the configuration
works (see next commits).

 * Bundle::registerExtensions() method has been renamed to Bundle::build()

 * The "main" DIC extension must be renamed to the new convention to be
   automatically registered:

      SensioBlogBundle -> DependencyInjection\SensioBlogExtension

 * The main DIC extension alias must follow the convention:

      sensio_blog for SensioBlogBundle

 * If you have more than one extension for a bundle (which should really
   never be the case), they must be registered manually by overriding the
   build() method

 * If you use YAML or PHP for your configuration, renamed the following
   configuration entry points in your configs:

      app -> framework
      webprofiler -> web_profiler
      doctrine_odm -> doctrine_mongo_db
2011-02-15 22:11:07 +01:00
Fabien Potencier
e5403490e7 removed the need to define getNamespace() and getPath() in bundles 2011-02-05 22:40:30 +01:00
Fabien Potencier
f455700b88 fixed previous commit 2011-02-04 12:18:26 +01:00
Victor Berchet
3ed47114d6 [Bundle] Make getPath() less error prone by allowing both backward and forward slashes 2011-02-04 12:12:19 +01:00
Fabien Potencier
6d1e91a1fa refactored bundle management
Before I explain the changes, let's talk about the current state.

Before this patch, the registerBundleDirs() method returned an ordered (for
resource overloading) list of namespace prefixes and the path to their
location. Here are some problems with this approach:

 * The paths set by this method and the paths configured for the autoloader
   can be disconnected (leading to unexpected behaviors);

 * A bundle outside these paths worked, but unexpected behavior can occur;

 * Choosing a bundle namespace was limited to the registered namespace
   prefixes, and their number should stay low enough (for performance reasons)
   -- moreover the current Bundle\ and Application\ top namespaces does not
   respect the standard rules for namespaces (first segment should be the
   vendor name);

 * Developers must understand the concept of "namespace prefixes" to
   understand the overloading mechanism, which is one more thing to learn,
   which is Symfony specific;

 * Each time you want to get a resource that can be overloaded (a template for
   instance), Symfony would have tried all namespace prefixes one after the
   other until if finds a matching file. But that can be computed in advance
   to reduce the overhead.

Another topic which was not really well addressed is how you can reference a
file/resource from a bundle (and take into account the possibility of
overloading). For instance, in the routing, you can import a file from a
bundle like this:

  <import resource="FrameworkBundle/Resources/config/internal.xml" />

Again, this works only because we have a limited number of possible namespace
prefixes.

This patch addresses these problems and some more.

First, the registerBundleDirs() method has been removed. It means that you are
now free to use any namespace for your bundles. No need to have specific
prefixes anymore. You are also free to store them anywhere, in as many
directories as you want. You just need to be sure that they are autoloaded
correctly.

The bundle "name" is now always the short name of the bundle class (like
FrameworkBundle or SensioCasBundle). As the best practice is to prefix the
bundle name with the vendor name, it's up to the vendor to ensure that each
bundle name is unique. I insist that a bundle name must be unique. This was
the opposite before as two bundles with the same name was how Symfony2 found
inheritance.

A new getParent() method has been added to BundleInterface. It returns the
bundle name that the bundle overrides (this is optional of course). That way,
there is no ordering problem anymore as the inheritance tree is explicitely
defined by the bundle themselves.

So, with this system, we can easily have an inheritance tree like the
following:

FooBundle < MyFooBundle < MyCustomFooBundle

MyCustomFooBundle returns MyFooBundle for the getParent() method, and
MyFooBundle returns FooBundle.

If two bundles override the same bundle, an exception is thrown.

Based on the bundle name, you can now reference any resource with this
notation:

    @FooBundle/Resources/config/routing.xml
    @FooBundle/Controller/FooController.php

This notation is the input of the Kernel::locateResource() method, which
returns the location of the file (and of course it takes into account
overloading).

So, in the routing, you can now use the following:

    <import resource="@FrameworkBundle/Resources/config/internal.xml" />

The template loading mechanism also use this method under the hood.

As a bonus, all the code that converts from internal notations to file names
(controller names: ControllerNameParser, template names: TemplateNameParser,
resource paths, ...) is now contained in several well-defined classes. The
same goes for the code that look for templates (TemplateLocator), routing
files (FileLocator), ...

As a side note, it is really easy to also support multiple-inheritance for a
bundle (for instance if a bundle returns an array of bundle names it extends).
However, this is not implemented in this patch as I'm not sure we want to
support that.

How to upgrade:

 * Each bundle must now implement two new mandatory methods: getPath() and
   getNamespace(), and optionally the getParent() method if the bundle extends
   another one. Here is a common implementation for these methods:

    /**
     * {@inheritdoc}
     */
    public function getParent()
    {
        return 'MyFrameworkBundle';
    }

    /**
     * {@inheritdoc}
     */
    public function getNamespace()
    {
        return __NAMESPACE__;
    }

    /**
     * {@inheritdoc}
     */
    public function getPath()
    {
        return strtr(__DIR__, '\\', '/');
    }

 * The registerBundleDirs() can be removed from your Kernel class;

 * If your code relies on getBundleDirs() or the kernel.bundle_dirs parameter,
   it should be upgraded to use the new interface (see Doctrine commands for
   many example of such a change);

 * When referencing a bundle, you must now always use its name (no more \ or /
   in bundle names) -- this transition was already done for most things
   before, and now applies to the routing as well;

 * Imports in routing files must be changed:
    Before: <import resource="Sensio/CasBundle/Resources/config/internal.xml" />
    After:  <import resource="@SensioCasBundle/Resources/config/internal.xml" />
2011-01-20 18:42:47 +01:00
Dominique Bongiraud
64fb94c725 normalized license messages in PHP files 2011-01-18 08:07:46 +01:00
Fabien Potencier
8e6a3849ee [TwigBundle] converted the special Twig Environment class to a DIC compiler class 2010-12-23 12:58:31 +01:00
Kris Wallsmith
f79e23ffb5 Removed all those spaces after @author that were bothering me so… 2010-10-18 16:55:41 +02:00
Fabien Potencier
d657adbfa2 removed Symfony\Framework
Things have been moved to Symfony\Component\HttpKernel
and Symfony\Bundle\FrameworkBundle

The kernel configuration namespace was removed and merged
with the main web configuration namespace (kernel:config => web:config,
kernel:test => web:test, and kernel:session => web:session):

Before:
<kernel:config charset="UTF-8" error_handler="null" />

<web:config csrf-secret="xxxxxxxxxx">
    <web:router resource="%kernel.root_dir%/config/routing.xml" />
    <web:validation enabled="true" annotations="true" />
</web:config>

After:
<web:config csrf-secret="xxxxxxxxxx" charset="UTF-8" error-handler="null">
    <web:router resource="%kernel.root_dir%/config/routing.xml" />
    <web:validation enabled="true" annotations="true" />
</web:config>

Renamed classes:

Symfony\{Framework => Bundle\FrameworkBundle}\Cache\Cache
Symfony\{Framework => Bundle\FrameworkBundle}\Client
Symfony\{Framework => Bundle\FrameworkBundle}\Debug\EventDispatcher
Symfony\{Framework => Bundle\FrameworkBundle}\Debug\EventDispatcherTraceableInterface
Symfony\{Framework => Bundle\FrameworkBundle}\EventDispatcher
Symfony\{Framework => Component\HttpFoundation}\UniversalClassLoader
Symfony\{Framework => Component\HttpKernel}\Bundle\Bundle
Symfony\{Framework => Component\HttpKernel}\Bundle\BundleInterface
Symfony\{Framework => Component\HttpKernel}\ClassCollectionLoader
Symfony\{Framework => Component\HttpKernel}\Debug\ErrorException
Symfony\{Framework => Component\HttpKernel}\Debug\ErrorHandler
Symfony\{Bundle\FrameworkBundle => Component\HttpKernel}\Debug\ExceptionListener
Symfony\{Framework => Component\HttpKernel}\Kernel
2010-09-17 12:58:24 +02:00
Fabien Potencier
17bc06a4d2 made some cleanup 2010-08-10 16:13:51 +02:00
Fabien Potencier
9e82497d5b removed BundleInterface::buildContainer() method (extensions are now automatically registered -- or override the getExtensions() method if you do not follow the conventions) 2010-08-10 16:07:44 +02:00
Kris Wallsmith
fa3980f66f Removed some use statements that are no longer needed. 2010-08-04 07:37:12 +02:00
Fabien Potencier
ee2ff39eaf removed @package and @subpackage annotations 2010-08-01 23:06:28 +02:00
Fabien Potencier
1a9f2ca755 updated PHPDoc as the API tool knows about the current use statements 2010-07-27 15:33:28 +02:00
Fabien Potencier
2a051b5039 moved DI extensions classes to their own sub-namespace 2010-07-16 11:12:49 +02:00
Fabien Potencier
7796eb213c merged BuilderConfiguration and Builder classes into a new ContainerBuilder class 2010-07-15 15:20:41 +02:00
Fabien Potencier
0163178f7b changed the BundleInterface::buildContainer() signature 2010-07-13 12:34:33 +02:00
Fabien Potencier
da9f36ca86 renamed Symfony\Foundation to Symfony\Framework
In existing applications, you need to updated the autoload.php file, the
XXXKernel file and all XXXBundle classes.
2010-07-09 10:25:54 +02:00
Fabien Potencier
6213fdefb9 renamed Symfony\Framework to Symfony\Bundle
For existing Symfony2 applications, references to Symfony\Framework are found
in the main Kernel class (registerBundles() and registerBundleDirs()), and in
all Controller classes. You also need to change the console script.
2010-07-09 10:25:15 +02:00