I like solution 1, considering that Symfony2 is aiming to be a more verbose
framework, indicating that a resource is a file wont hurt?
t
On Tue, Nov 30, 2010 at 18:42, 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<symfony-devs%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
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
