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
