On 2/23/10 9:04 AM, Jordi Boggiano wrote:
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.
I'm not sure I understand your concern here. The "resource" thing
imports ALL the routes from a given file. And when you add the prefix,
it is added in front of all the routes from the imported file. So,
basically, the resource parameter IS an import statement like we have in
the DIC.
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.
It definitely should. One more thing: the parameter MUST be defined
AFTER setting the kernel configuration:
kernel.config: ~
parameters:
request.class: My\Request
That's probably not what people expect though. We need to work on that
for sure.
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
You can do the exact same thing with Symfony 2 of course. That's a
matter of taste. But we need a simple and easy way for newcomers to get
started fast.
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,
Fabien
Cheers,
Jordi
--
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.
