We have in our own systems used the resourceName: which have worked
out quite well.
Instead of always specifying the resource to use, cant we fallback to
file if theres no prefix?
On Nov 30, 8:42 am, Fabien Potencier <fabien.potenc...@symfony-
project.com> wrote:
> Hi all,
>
> Time for another RFC. Today, I want your opinion on custom loader
> resources notation.
>
> As you might know, the Dependency Injection and Routing components have
> the notion of loaders. A loader is able to load "resource"s. A resource
> can be anything; write a loader that knows how to load the resource and
> you're good to go. Both components comes with built-in file loaders for
> XML, YAML, and PHP:
>
> # config.yml
> imports:
> - { resource: security.yml }
>
> # routing.yml
> imports
> - { resource: BlogBundle/Resources/config/routing.xml, prefix: /blog }
>
> The interesting part is that a resource is not necessarily a file. Of
> course, most of the time, this is part of a file path, but it does not
> need to.
>
> For instance, if you have a look at the Routing component and the
> FrameworkExtraBundle documentation, you will see that there is a special
> "annotation" loader. For this annotation loader, the resource is not a
> file path but it can be a glob or a directory of files to parse for
> annotations:
>
> imports:
> - { resource: annotations:BlogBundle/Controller/AnnotController.php }
>
> As you can see, the current convention is to to prefix the "real"
> resource by a word followed by a colon, here "annotations:".
>
> Symfony2 determines the loader to use via a LoaderResolverInterface
> instance. Here is the default implementation of this interface:
>
> public function resolve($resource)
> {
> foreach ($this->loaders as $loader) {
> if ($loader->supports($resource)) {
> return $loader;
> }
> }
>
> return false;
> }
>
> So, each loader has a supports() method that must return true if it is
> able to load the resource. Here is for instance the supports() method
> for the PHP and XML loader:
>
> // PHP
> public function supports($resource)
> {
> return is_string($resource)
> && 'php' === pathinfo($resource, PATHINFO_EXTENSION)
> && is_file($this->getAbsolutePath($resource));
> }
>
> // XML
> public function supports($resource)
> {
> return is_string($resource)
> && 'xml' === pathinfo($resource, PATHINFO_EXTENSION);
> }
>
> As you can see, for the annotation loader to work, the PHP loader checks
> if the resource is actually an existing file; which is not the case for
> XML loader.
>
> I had to do that because of the registration order. If you remove the
> 'is_file' check in the PHP loader and register the annotation loader
> after the PHP one, the PHP loader will always "win" but won't be able to
> do anything useful with the resource.
>
> So, we need a way to clearly identify which loader need to be used. The
> current implementation of the PHP loader is a "hack" as you won't have a
> proper exception if you want to load a PHP resource and if you make a
> typo in the file path because the loader will tell the resolver that it
> does not support the resource. So, you will have an exception saying
> that there is no loader able to load your resource, which is not the
> real problem (you have a typo in the file path).
>
> everzet had the same problem and came up with a
> patch:https://github.com/fabpot/symfony/pull/178
>
> In this pull request, we talked about the prefix to use, and one
> proposal (the one implemented in the patch) was to use (), as they
> cannot be used at the beginning of a real file path. So, to create a
> custom loader, you need prefix the resource like this:
>
> imports:
> - { resource: (annotations) BlogBundle/Controller/AnnotController.php }
>
> I was about to merge the change and then I step back and found this
> convention quite ugly (I was the one to propose that).
>
> I thought about that more and here are some proposals:
>
> 1/ Always prefix the path with something, even for file resources (like
> a DSN):
>
> imports:
> - { resource: file:BlogBundle/Controller/AnnotController.php }
> - { resource: annotations:BlogBundle/Controller/AnnotController.php }
>
> * This is explicit, no ambiguity possible, simple supports()
> implementation, clear error messages;
> * But when using a file as a resource, which is what you will do most
> of the time, you will have to use the 'file:' prefix.
>
> 2/ Use a prefix for everything except file loaders
>
> For this one, we need to come up with a convention that can be easily
> checked and cannot be part of a file name:
>
> (annotations) BlogBundle/Controller/AnnotController.php
> annotations::BlogBundle/Controller/AnnotController.php
> [annotations]BlogBundle/Controller/AnnotController.php
> ...
>
> 3/ You own idea here ;)
>
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead developer
> sensiolabs.com | symfony-project.org | fabien.potencier.org
> Tél: +33 1 40 99 80 80
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
