Commits
-------
f09789b [FrameworkBundle] Generate the class cache when warming up the cache
Discussion
----------
[FrameworkBundle] Generate the class cache when warming up the cache
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/jalliot/symfony)
Fixes the following tickets: -
Todo: -
With this PR, the commands `cache:clear` (if `--no-warmup` hasn't been specified) and `cache:warmup` generate the class cache. Now the first page load after clearing the cache does not take over one second anymore :)
Of course, if someone does not want to use the class cache for whatever reason, he can always remove the `$kernel->loadClassCache()` in his front controller and the cache will just be ignored...
On a side note, can someone explain why [SensioDistributionBundle does not warmup the cache in the Composer post-install script](https://github.com/sensio/SensioDistributionBundle/blob/master/Composer/ScriptHandler.php#L48)?
---------------------------------------------------------------------------
by travisbot at 2012-06-10T05:18:30Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1579114) (merged baecbaee into 6266b72d).
---------------------------------------------------------------------------
by travisbot at 2012-06-10T05:24:48Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1579154) (merged f09789b1 into 6266b72d).
---------------------------------------------------------------------------
by jalliot at 2012-06-28T23:18:54Z
@fabpot ping
this is useful for a CMS, where in most cases there will be too many routes to make it feasible to load all of them. here a router implementation will be used that will return an empty collection for ->all(). with this refactoring the given routes will not be listed via router:debug, but would still be shown when using router:debug [name]
Commits
-------
df11e62 [FrameworkBundle] Used $output->write() instead of echo
c3bf479 [FrameworkBundle] Used Process component
cfa2dff [FrameworkBundle] Changed server:run command description
e7d38c1 [FrameworkBundle] Changed PHP version detection (see: #3529)
4a3f6d5 [FrameworkBundle] Removed global variable from router script
519d431 [FrameworkBundle] Fixed built-in server router script
d9a0a17 [FrameworkBundle] Added server:run command
Discussion
----------
[FrameworkBundle] Added server:run command (PHP 5.4 built-in web server)
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/michal-pipa/symfony)
Fixes the following tickets: -
Todo: -
PHP 5.4 comes with [built-in web server](http://www.php.net/manual/en/features.commandline.webserver.php). I've created command which allows to easily run Symfony2 application using this new feature.
Usage:
server:run [-d|--docroot="..."] [-r|--router="..."] [address]
Arguments:
address Address:port (default: 'localhost:8000')
Options:
--docroot (-d) Document root (default: 'web/')
--router (-r) Path to custom router script
Help:
The server:run runs Symfony2 application using PHP built-in web server:
app/console server:run
To change default bind address and port use the address argument:
app/console server:run 127.0.0.1:8080
To change default docroot directory use the --docroot option:
app/console server:run --docroot=htdocs/
If you have custom docroot directory layout, you can specify your own
router script using --router option:
app/console server:run --router=app/config/router.php
See also: http://www.php.net/manual/en/features.commandline.webserver.php
It requires PHP 5.4, otherwise this command will be disabled.
I think that this is very convenient (especially for new users). All you have to do is download Symfony, install vendors and run this command. You don't have to configure "real" web server, in fact any other server is not required. You don't have cache and logs permission problem, because server runs with your local user permissions.
---------------------------------------------------------------------------
by blogsh at 2012-03-06T17:38:10Z
Great feature! I was about to write something like this when I saw that you have already started implementing this :)
Some issues:
1. Missing newlines at the end of the files
2. If I try this server command with the default Symfony Standard Edition Acme demo the links on the main page do not work. The demo link links to "//demo" and the configurator link to "//_configurator". If I go to `localhost:8000/demo` directly the page is rendered as usual and all sub links are generated correctly. I could solve the problem by adding one line:
$_SERVER['SCRIPT_FILENAME'] = 'ANYTHING';
require 'app_dev.php';
I'm not sure where this problem comes from. Do you experience the same behaviour? Otherwise I'll do some more investigations to find the source of the problem.
3 . I think it would be a nice feature if you would generate a router.php based on the setting of the --env flag if no custom router file has been specified. This way it would be easy to switch between dev and prod.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-06T19:00:24Z
@blogsh
> Missing newlines at the end of the files
I've checked and I can see newlines at the end of files. Are you sure about this?
> If I try this server command with the default Symfony Standard Edition Acme demo the links on the main page do not work. The demo link links to "//demo" and the configurator link to "//_configurator". If I go to localhost:8000/demo directly the page is rendered as usual and all sub links are generated correctly. I could solve the problem by adding one line:
>
> $_SERVER['SCRIPT_FILENAME'] = 'ANYTHING';
> require 'app_dev.php';
>
> I'm not sure where this problem comes from. Do you experience the same behaviour? Otherwise I'll do some more investigations to find the source of the problem.
I can reproduce this by changing front controller name from `app.php` to `app_dev.php`. I'll investigate on this.
> I think it would be a nice feature if you would generate a router.php based on the setting of the --env flag if no custom router file has been specified. This way it would be easy to switch between dev and prod.
You can easily change environment specifying front controller in URL. It works exactly the same way as default Apache configuration. This is intended behavior, as it would be misleading if every server had different rewrite rules.
If you really want to change it, then you can write your own router and pass it as a value to `router` option.
---------------------------------------------------------------------------
by blogsh at 2012-03-06T19:13:55Z
Wasn't aware that github omits the trailing white line, sorry.
Normally I use a rather inflexible nginx configuration, so I also wasn't aware of this (rather obvious) trick of changing the url. Thanks for that.
---------------------------------------------------------------------------
by stof at 2012-03-06T22:12:16Z
@blogsh it does not omit it. It displays it in the Linux way where the newline char is part of the line (and so there is a message ``no newline at end of file`` in the diff when it is missing).
---------------------------------------------------------------------------
by michal-pipa at 2012-03-07T07:18:23Z
@blogsh I've fixed router script. Now you can use both front controllers.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-07T07:34:58Z
I've also hardcoded front controller name in router script and removed global variable, as there was no way to unset it.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-13T07:57:04Z
I've used Process component, but now I don't get any stdout output (only stderr).
---------------------------------------------------------------------------
by michal-pipa at 2012-03-13T18:01:58Z
I've replaced `echo` by `$output->write()` and removed `$process` as it was not used actually.
Commits
-------
3ae976c fixed CS
84ad40d added cache clear hook
Discussion
----------
[Cache][2.1] Added cache clear hook
Allows bundles to hook into the `cache:clear` command by using the `kernel.cache_clearer` tag instead of using the `event_dispatcher` service.
See #1884
Bug fix: No
Feature addition: Yes
Backwards compatibility break: No
Symfony2 tests pass: Yes
Fixes the following tickets: #1884
References the following tickets: #1884
---------------------------------------------------------------------------
by dustin10 at 2011/12/16 11:03:54 -0800
Rebased to squash all commits into one.
---------------------------------------------------------------------------
by lsmith77 at 2011/12/17 05:27:29 -0800
@fabpot: we figured that priorities wouldn't be needed for cleaning .. haven't tested the PR, but conceptually it looks good to me and aside from the priority stuff its modeled after the cache warners.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 09:46:26 -0800
@fabpot Updated to pass cache dir to `clear` method.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:02:21 -0800
@stof and @fabpot Another thought I just had. Should the `$this->getContainer()->get('cache_clearer')->clear($realCacheDir);` call in the `CacheClearCommand` be done before the warming?
---------------------------------------------------------------------------
by stof at 2011/12/19 10:03:59 -0800
indeed. the clearing should be done before the warming.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:19:28 -0800
Squashed all commits into one. Let me know if there is anything else.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:31:50 -0800
Fixed extra lines.
Commits
-------
63d2ce2 [FrameworkBundle] Fixed the ckeck for the router class
Discussion
----------
[FrameworkBundle] Fixed the ckeck for the router class
The getRouteCollection method is now part of the RouterInterface so the
command should accept any implementation of the interface instead of just
the implementations extending the core one.
The getRouteCollection method is now part of the RouterInterface so the
command should accept any implementation of the interface instead of just
the implementations extending the core one.
Commits
-------
dd20f01 Fixed assets:install to use a relative path instead of an absolute
Discussion
----------
[2.1] Fixed "assets:install" to create relative instead of absolute symlinks
This is a fairly simple fix so that the symlinks are relative to the resources rather than an absolute path that breaks from machine-to-machine or upon deployment.
We were trying to figure out why styles were messed up for other contributors, but then found that the paths were hard-coded for my machine :)
---------------------------------------------------------------------------
by ericclemmons at 2011/06/04 09:44:11 -0700
Any other thoughts/updates on this?
---------------------------------------------------------------------------
by fabpot at 2011/06/04 22:31:39 -0700
We have such a feature in symfony1 and IIRC it does not work very well. One problem is when you use symlink for some bundles. Then, you should not use a relative symlink as there is a common path between the two.
---------------------------------------------------------------------------
by ericclemmons at 2011/06/05 09:55:00 -0700
Sorry, I didn't think that we would be an issue since the Bundle "Best Practices" states to not include other bundles as dependencies.
If absolute links are a must, then the next alternative is for collaborators to add "/web/bundles" to .gitignore and each person run "assets:install" upon installation/update.
I was personally hoping there were a way to have this versioned for easier deployment.
On Jun 5, 2011, at 12:31 AM, fabpot<reply@reply.github.com> wrote:
> We have such a feature in symfony1 and IIRC it does not work very well. One problem is when you use symlink for some bundles. Then, you should not use a relative symlink as there is a common path between the two.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1173#issuecomment-1303600
---------------------------------------------------------------------------
by henrikbjorn at 2011/06/27 04:56:58 -0700
``` php
<?php
// ...
->addOption('relative', null, InputOption::VALUE_NONE, 'The --symlink option will generate relative paths')
// ...
```
and just default to absolute paths ?
---------------------------------------------------------------------------
by ericclemmons at 2011/06/27 08:37:50 -0700
I'm very supportive of that compromise. Up to @fabpot if I should add this back in, since relative paths were apparently problematic with symfony1.
---------------------------------------------------------------------------
by sbusch at 2011/07/15 08:46:01 -0700
+1
I'm developing on Mac and the files are mounted on a Linux box which serves the project. The paths are not the same on those two systems. If I accidentally install assets on my Mac the absolute paths won't work on the Linux webserver.
Other scenario: one teammate could add those symlinks by accident to the git repository, which breaks all other installations.
Relative symlinks could help a lot in these cases.
---------------------------------------------------------------------------
by ericclemmons at 2011/07/15 08:47:53 -0700
@sbusch Your issues are the same as mine, which prompted this ticket :)
Until this gets @fabpot's blessing, it's best to simply add `web/bundles` to your `.gitignore` file and tell your users to always run `assets:install --symlink` each time they pull down code & something breaks ;)
---------------------------------------------------------------------------
by sbusch at 2011/07/15 08:58:33 -0700
The handling (calculation) of relative symlinks IMO fits better to the `symlink()` method of `\Symfony\Component\HttpKernel\Util\Filesystem`. Possible method signature:
symfony/src/Symfony/Component/HttpKernel/Util/Filesystem.php:
```php
<?php
// ...
/**
* Creates a symbolic link or copy a directory.
*
* @param string $originDir The origin directory path
* @param string $targetDir The symbolic link name
* @param Boolean $copyOnWindows Whether to copy files if on Windows
* @param Boolean $makeRelative Whether to try to create a relative link
*/
public function symlink($originDir, $targetDir, $copyOnWindows = false, $makeRelative = false)
{
```
And what about changing the `--symlink` option to optionally have a value, instead of adding a new depending option? E.g. `--symlink[=absolute|relative]`, with "absolute" as default:
symfony/src/Symfony/Bundle/FrameworkBundle/Command/AssetsInstallCommand.php:
```php
<?php
// ...
class AssetsInstallCommand extends ContainerAwareCommand
{
/**
* @see Command
*/
protected function configure()
{
$this
->setDefinition(array(
new InputArgument('target', InputArgument::REQUIRED, 'The target directory (usually "web")'),
))
->addOption('symlink', null, InputOption::VALUE_OPTIONAL, 'Symlinks the assets instead of copying it. Allowed values: "absolute" (default) and "relative".', 'absolute')
->setHelp(<<<EOT
The <info>assets:install</info> command installs bundle assets into a given
directory (e.g. the web directory).
<info>./app/console assets:install web [--symlink]</info>
A "bundles" directory will be created inside the target directory, and the
"Resources/public" directory of each bundle will be copied into it.
To create a symlink to each bundle instead of copying its assets, use the
<info>--symlink</info> option. Use <info>--symlink=relative</info> for relative symlinks.
EOT
)
->setName('assets:install')
;
}
/**
* @see Command
*
* @throws \InvalidArgumentException When the target directory does not exist
*/
protected function execute(InputInterface $input, OutputInterface $output)
{
if (!is_dir($input->getArgument('target'))) {
throw new \InvalidArgumentException(sprintf('The target directory "%s" does not exist.', $input->getArgument('target')));
}
if ($input->hasOption('symlink'))
{
if (!function_exists('symlink')) {
throw new \InvalidArgumentException('The symlink() function is not available on your system. You need to install the assets without the --symlink option.');
}
if (!in_array($input->getOption('symlink'), array('absolute', 'relative'))) {
throw new \InvalidArgumentException(sprintf('Invalid value "%s" for option "symlink"', $input->getOption('symlink')));
}
}
$filesystem = $this->getContainer()->get('filesystem');
// Create the bundles directory otherwise symlink will fail.
$filesystem->mkdir($input->getArgument('target').'/bundles/', 0777);
foreach ($this->getContainer()->get('kernel')->getBundles() as $bundle) {
$originDir = $bundle->getPath().'/Resources/public';
if (is_dir($originDir)) {
$targetDir = $input->getArgument('target').'/bundles/'.preg_replace('/bundle$/', '', strtolower($bundle->getName()));
$output->writeln(sprintf('Installing assets for <comment>%s</comment> into <comment>%s</comment>', $bundle->getNamespace(), $targetDir));
$filesystem->remove($targetDir);
if ($input->hasOption('symlink')) {
$filesystem->symlink($originDir, $targetDir, false, $input->getOption('symlink') == 'relative');
} else {
$filesystem->mkdir($targetDir, 0777);
$filesystem->mirror($originDir, $targetDir);
}
}
}
}
```
---------------------------------------------------------------------------
by sbusch at 2011/07/15 09:04:46 -0700
@ericclemmons: yes, that's our current workaround. I started with manually converting absolute links to relative ones, but that quickly got very annoying ;-)
After that I tried to implement the generation of relative links by myself (where the proposals of my previous comment come from) until I found your PR.
---------------------------------------------------------------------------
by henrikbjorn at 2011/07/18 00:20:38 -0700
@sbush if it defaults to something how would you turn it off ?
---------------------------------------------------------------------------
by stof at 2011/07/18 00:26:16 -0700
@henrikbjorn a default value for the option is used when using ``--symlink`` without the value. If you don't use the option at all, it is disabled.
---------------------------------------------------------------------------
by stof at 2011/07/18 11:58:29 -0700
In fact no. The default value seems to be also used when the option is not set at all. @fabpot is this intended ?
---------------------------------------------------------------------------
by Seldaek at 2011/07/19 05:18:29 -0700
Symlinks on windows, although technically possible, don't quite work with PHP on most setups. Also git doesn't seem to support them either on windows (not sure why not). For those reasons, and although I'm sure this doesn't apply to every project, I would recommend you just have everyone run `assets:install [--symlink]` on their local machine, and make that command run on the server as part of your deployment process.
---------------------------------------------------------------------------
by ericclemmons at 2011/07/19 06:15:34 -0700
Nobody is even entertaining --relative?
On Jul 19, 2011, at 7:18 AM, Seldaek<reply@reply.github.com> wrote:
> Symlinks on windows, although technically possible, don't quite work with PHP on most setups. Also git doesn't seem to support them either on windows (not sure why not). For those reasons, and although I'm sure this doesn't apply to every project, I would recommend you just have everyone run `assets:install [--symlink]` on their local machine, and make that command run on the server as part of your deployment process.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1173#issuecomment-1606463
---------------------------------------------------------------------------
by Gregwar at 2011/08/10 08:56:27 -0700
I agree with the idea of proposing a --relative option, I'm currently working on a Samba mounted filesystem and I'm forced to create manually symlinks to get things working since the paths are not the same
Commits
-------
d675c28 [FrameworkBundle] Use Router instead of RouterInterface
ae7ae8d [FrameworkBundle] Moved router_listener from web to router.xml since it depends on the router
35a9023 [FrameworkBundle] Added isEnabled to Router commands, fixes#1467536d979 [Console] Added Command::isEnabled method that defines whether to add the command or not
Discussion
----------
[2.1] [Console] Added Command::isEnabled method
This addresses #1467.
The idea is to allow commands to evaluate whether they can run or not, since they are automatically registered.
- It's useful for the two router:* commands since they're optional (router can be disabled), but part of the FrameworkBundle that is not really optional.
- It could be useful for third party code as well.
- It's BC.
- aa95bb0d395810b29a3e654673e130736d9d1080 should address the issue in #1467, while the other commits just make sure the command is not registered at all if the router isn't standard.
One issue remains though:
- A few other services like twig helpers get the `ròuter` injected, this means that if there is really **no** router service defined, there is still an error. I'm not sure how to fix those beyond adding `on-invalid="null"` but I'm not sure if that's desirable. I guess we could argue that the router is a big candidate for replacement/suppression, and as such it should be truly optional, but if we do it I don't know where it'll lead. I don't want to end up in a situation where half the dependencies are optional to support every possible combination. @fabpot wdyt?
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/28 16:19:46 -0700
I'd rather see us not register a command instead of register and then disable it. Can we do the same thing you've done here in the bundle's registerCommands() method?
---------------------------------------------------------------------------
by Seldaek at 2011/06/28 16:51:36 -0700
Note that it's never really registered. During the registration it's checked and skipped if not enabled.
However, doing it as you suggest means overriding/copy-pasting all the code from the core Bundle class, which I don't like so much. It also means adding code specific to those two commands in a somewhat unrelated place, which I also don't like.
I'm not saying the current solution is perfect, but from the alternatives I considered, it's the best I have found.
---------------------------------------------------------------------------
by stof at 2011/09/04 04:58:04 -0700
@Seldaek your branch conflicts with master. could you rebase it ?
@fabpot what do you think about this PR ?
---------------------------------------------------------------------------
by Seldaek at 2011/09/04 08:39:05 -0700
Rebased
-- add missing files
-- tweak translation command files
-- dumpers are now responsive for writting the files
-- moved the twig extractor the bridge
-- clear temp files after unit tests
-- check the presence of dumper in translation writer
-- General cleaning of the code
-- clean phpDoc
-- fix PHPDoc
-- fixing class name in configuration
-- add unit tests for extractors (php and twig)
-- moved test to correct location
-- polish the code
-- polish the code
* 2.0:
[Validator] Sync polish translation
[FrameworkBundle] sanitize target arg in asset:install command
few optimisations for XliffFileLoader and XmlFileLoader
[FrameworkBundle] Sync the Russian translations
[FrameworkBundle] Added Dutch validator translation for trans-unit 41
[FrameworkBundle] Updated German validator translation
[FrameworkBundle] Fixed a typo in the translation file per @PeymanHR
Here are the new simplified rules:
* Required cache warmers are *always* executed when the Kernel boots for the first time;
* Optional cache warmers are *only* executed from the CLI via cache:warmup
These new rules means that all the configuration settings for the cache
warmers have been removed. So, if you want the best performance, remember to
warmup the cache when going to production.
This also fixed quite a few bugs.
As it has recently been discussed [on the mailing-list][1], windows doesn't
support symlinks for the assets:install command. In order to avoid a 'call to
undefined-function'-message in this case, this patch adds an exception which
will be thrown when the symlink-funktion isn't present and the
`--symlink`-Option was specified.
[1]: https://groups.google.com/group/symfony-devs/browse_thread/thread/4b8ad9634bdab155
This is mirrored off of the messages used by git flow and serves to give the user some initial direction (and to avoid "forgetting" the setup steps).
I realize that I've hardcoded documentation URLs into this task, but I think the benefit outweighs the cost of needing to make sure these are always up-to-date.
This command uses a new container pass which dumps the ContainerBuilder into a cache file by serializing it. It's possible that we don't want this to run when kernel.debug = false, but I don't see the harm of generating the file and running the container:debug in, for example, the prod environment seems to make sense.
* Added the --format parameter to the InitBundleCommand.php file
* Moved all the non-format-dependent files from Resources/skeleton/bundle to Resources/skeleton/bundle/generic
* Created Resources/skeleton/bundle/[php,yml,xml] subfolders containing the files config/routing.[xml,yml,php]
Cache warmer will come in the next commits.
To warm up the cache on a production server, you can use
the cache:warmup command:
./app/console_prod cache:warmup
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" />
Let's take some examples to explain the change.
First, if you don't use any vendored bundles, this commit does not change anything.
So, let's say you use a FooBundle from Sensio. The files are stored under Bundle\Sensio\FooBundle.
And the Bundle class is Bundle\Sensio\FooBundle\SensioFooBundle.php.
Before the change, the bundle name ($bundle->getName()) would have returned 'FooBundle'.
Now it returns 'SensioFooBundle'.
Why does it matter? Well, it makes template names and controller names easier to read:
Before:
Template: Sensio\FooBundle:Bar:index.twig.html
Controller: Sensio\FooBundle:Bar:indexAction
After
Template: SensioFooBundle:Bar:index.twig.html
Controller: SensioFooBundle:Bar:indexAction
NB: Even if the change seems simple enough, the implementation is not. As finding
the namespace from the bundle class name is not trivial
NB2: If you don't follow the bundle name best practices, this will probably
leads to unexpected behaviors.
To keep language consistent, three methods were changed in InputOption:
* `InputOption::acceptParameter()` -> `InputOption::acceptValue()`
* `InputOption::isParameterRequired()` -> InputOption::isValueRequired()`
* `InputOption::isParameterOptional()` -> `InputOption::isValueOptional()`
The InputDefinition::asXml() method was also modified to update the `accept_value` and `is_value_required` attributes.
* removed the __call() method in Container: it means that now, there is only
one way to get a service: via the get() method;
* removed the $shared variable in the dumped Container classes (we now use
the $services variable from the parent class directly -- this is where we
have a performance improvement);
* optimized the PHP Dumper output.
