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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
