Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Override service and configuration #1457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 21, 2012

Conversation

Burgov
Copy link
Contributor

@Burgov Burgov commented Jun 14, 2012

reopened #1421 based on the correct branch

Bart van den Burg and others added 2 commits May 31, 2012 17:29
@Burgov
Copy link
Contributor Author

Burgov commented Jun 14, 2012

@weaverryan first of all, congratulations on getting married! I hope you had a great day and that it was worth missing Symfony Live for ;)

I've updated the text as per your comments. I decided to keep the part about setting the param from your extension. For example, we use a Framework bundle, which overrides a service of the Symfony FrameworkBundle. I want it to do this automatically whenever it is included in a project, so we don't need to keep all our config.yml's synced. By setting the param in the Extension class, I don't need to worry about this

@stof
Copy link
Member

stof commented Jun 14, 2012

@Burgov by setting the param in your DI extension, it works only when registering your bundle after FrameworkBundle (as the last one setting the param will win). And relying on the bundle order is a bad practice (shared bundles should never do it) so the doc should not give it as an example

class name by setting the parameter directly in the container in the Extension
class of your bundle:

.. code-block:: html+php
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

html+php ? where is the html code ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

http://symfony.com/doc/current/contributing/documentation/format.html states that when code contains <?php, it should be defined ad html+php
This part will be removed anyway

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, but there is no need to include <?php here as you are only showing some PHP code. html+php is only used for PHP templates in the doc (which indeed mix HTML and PHP)

@Burgov
Copy link
Contributor Author

Burgov commented Jun 14, 2012

I clearly need to read up on compiler passes. Had only been using them to define my own tags so far, but I seem to be missing out on a lot of features. I'll experiment with this and rewrite this PR this weekend. @stof Thanks for the pointers

@Burgov
Copy link
Contributor Author

Burgov commented Jun 16, 2012

@stof I've rewritten the text to include info on using Compiler Passes. Do you think the information is sufficient?

@cordoval
Copy link
Contributor

maybe add the following context:

your app src code
configuration of your bundles/ compiler passes

vendor bundles
configuration of vendor bundles /compiler passes

and talk about the best practice for moving custom hacky configuration into compiler passes for overriding vendor bundles configuration?

weaverryan added a commit that referenced this pull request Jun 21, 2012
@weaverryan weaverryan merged commit 04d64b6 into symfony:2.0 Jun 21, 2012
@weaverryan
Copy link
Member

Hey guys!

First, thank you very much - I'm still catching up a little bit from being gone for a week :). I think the information presented here is very good and fills in a section that people were looking for. I did make some modifications and additions - if you see any issues, please let me know.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants