I don't think that it is too verbose. In your xml example it is obvious that a xml file is the resource, but which loader understands the xml content of this file must be specified. IMO the protocol/loader should be specified like already in use everywhere, with :// as separator. And the url needs only to be understood by the loader, for example
dbsecurityloader://mysql://username:passw...@database/table should be considered valid (Or maybe it should be url-encoded???). Am 30.11.2010 16:59, schrieb Konstantin Kudryashov: > Extensions represent the type of resource. > > *xml*://path/to/routing.*xml* > *yml*://path/to/routing.*yml* > *php://path/to/routing.php* > > Is "overvorbose", IMO. All this loaders is firstly file loaders, so > > *file*:path/to/routing.*xml* > *file*:path/to/routing.*yml* > *file:path/to/routing.php* > > makes more sence to me. > Also, definitions like > > file*_://_*path/to/routing.xml > > is harder to read, because it's not clear to developer with what type of > path he works - absolute or relative. > > So, i'm still voting for: > > file:path/to/routing.yml > > --- > http://about.me/everzet/bio > > > > On Tue, Nov 30, 2010 at 17:49, Johannes <john_john...@gmx.de > <mailto:john_john...@gmx.de>> wrote: > > I also think 1) is the best option, but I'd use a different prefix. > This one can easily be confused with a key in Yaml, and a key it is > not. Besides as I understand it, the "file:" doesn't really represent > the type of the resource, but rather it indicates which loader is to > be used for whatever comes after the prefix. Therefore, "php://", > "xml://", etc. would be more precise, and less ambiguous; after all, > you'll also load annotations from a file, but you'll parse the file > differently. > > Regards, > Johannes > > > On 30 Nov., 16:30, Pablo Godel <pablo.go...@gmail.com > <mailto:pablo.go...@gmail.com>> wrote: > > As others mentioned, option #1 seems the more natural one. Adding > the file: > > prefix does not seem like an issue. > > > > Pablo > > -- > If you want to report a vulnerability issue on symfony, please send > it to security at symfony-project.com <http://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 > <mailto:symfony-devs@googlegroups.com> > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > <mailto: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
