Thanks for the quick answer, however it's still not so clear :) On 23.02.2010 07:10, Fabien Potencier wrote: >> That being said, I don't know if that pdo file is used at all so it >> might not matter. >> >> - Another question that troubles me a lot is how can I merge a full set >> of routes from a bundle to my main project.. I could import them all by >> manually writing them one by one like: >> >> blah: >> resource: path/to/routing.yml >> >> But that is hardly convenient once the routes start to multiply. > > Can you explain why it is not convenient? Most of the time, you will > probably need to prefix them anyway: > > blah: > resource: path/to/routing.yml > prefix: blog/ > > Do you expect to be able to import all routing from all enabled bundles? > But then, in which order? and without any prefix?
Of course I don't want that it imports everything, but I could see some
bundles having 10-15routes, and it sounds a bit stupid to have to
duplicate them all by hand if I want to use them as-is, let's say for a
blog or a forum the URL scheme is pretty standardized, I don't want to
remap them all by hand every time I use that bundle.
This in my opinion is a very good argument for the addition of the
"imports:" instruction to the Yaml Component.
>> - Also I would like to try to extend a core class from a random bundle,
>> namely the RequestHandler\Request class..
>>
>> I tried to add this to my config.yml, but it totally fails:
>>
>> foundation.services:
>> request.class: My\Request
>
> That's possible. You just need to "know" the parameter name for now as
> there are not exposed by the extensions... yet ;)
>
> So, to extend the request, you can do something like this:
>
> parameters:
> request.class: My\Request
I'm sorry but I still don't get that entirely.. Just adding what you
mention to the config.yml doesn't effectively change the request class,
is something missing from your example? I tried adding tons of different
things before but no success.
>> In my opinion this should be possible for *all* services, by default,
>> without the bundles having to voluntarily expose their classes as
>> parameters, otherwise the dependency injection is only smoke and mirrors
>> and only offers as much flexibility as the bundle author allowed. I find
>> the whole DI thing much more complicated to grasp than the plain one we
>> used in Okapi because of the multiple layers of abstraction that have
>> been added in Symfony 2. I hope this will fade away once I get it more,
>> or that it will be made a bit more transparent. The current approach
>> tries to make it really easy for the newbies to get into it and that is
>> great but if after half an hour you try to do something and get stuck
>> because the next step is overly complex because of it, then imo it is
>> not worth it.
>
> Using the extensions is just as you said a layer for newcomers. You can
> of course use the same interface as you use for Okapi. And correct me if
> I'm wrong, but you cannot change the class name if the service is not
> defined correctly with a parameter as the class.
Well.. the easier thing in okapi is that all services are defined very
explicitly like:
services:
api_command_doctrine:
class: api_command_doctrine
arguments:
routing: @routing
request: @request
response: @response
[...]
you only have the class, the constructor args and possibly the shared flag.
This can sit in an extension (or bundle) dir, and is imported, and if
you want to override it you just re-declare it completely, obviously you
can't just override the class name if it doesn't use a parameter, but at
least everything is accessible and you not encapsulated in that xml file
which does not seem to be overridable by default, since this doesn't
seem to work either..
services:
request:
class: Bundle\Request
As for github patches.. I'll try my best to get all that setup since I
have a few mini-patches but my git skills are very lame :)
Cheers,
Jordi
signature.asc
Description: OpenPGP digital signature
