Why not keep thing simple :
imports:
- { file: BlogBundle/Controller/AnnotController.php }
- { annotations: BlogBundle/Controller/AnnotController.php }
?
On 30 nov. 2010, at 09:35, Konstantin Kudryashov wrote:
> I like the idea of `file:` notation for default loaders. It's feeling more
> natural & Symfony2-ish =)
>
> ---
> http://about.me/everzet/bio
>
>
>
> On Tue, Nov 30, 2010 at 10:31, Miha Vrhovnik <miha.vrhov...@gmail.com>wrote:
>
>> The same way browser does?
>> file:///D:/foo/index.html
>>
>> M
>> On Nov 30, 9:15 am, Fabien Potencier <fabien.potenc...@symfony-
>> project.com> wrote:
>>> On 11/30/10 9:01 AM, Henrik Bjornskov wrote:
>>>
>>>> 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?
>>>
>>> Yes, this is the proposition number 2.
>>>
>>> But this is not possible with "something:resource". How do you
>>> differentiate between a path and a resource with a prefix?
>>>
>>> annotations:foobar
>>> c:\...
>>>
>>> Fabien
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> 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<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
--
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
