Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[DI][FrameworkBundle] Use container.hidden tag to hide services from debug:container#26891

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedApr 11, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?yes
Tests pass?yes
Fixed tickets#26630
LicenseMIT
Doc PR-

Now that services are private by default, thedebug:container should display them by default.
In fact, the public/private concept should not trigger a difference in visibility for this command.
Instead, I propose to handle a newcontainer.hidden tag, for the purpose of tagging services as hidden (~internal).

I now need to apply the tag to more services created internally.

Any comments at this stage?

ro0NL reacted with thumbs up emoji
Copy link
Member

@weaverryanweaverryan left a comment

Choose a reason for hiding this comment

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

Obviously, you know I like this idea. Particularly, it's important to now show ALL services indebug:container. The ability to then hide a few of themost internal, is great.

protectedfunctionexecute(InputInterface$input,OutputInterface$output)
{
if ($input->getOption('show-private')) {
@trigger_error('The "--show-private" option is a no-op and is deprecated since Symfony 4.1.',E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

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

option no longer has any effect and is deprecated ...

Copy link
Member

@stofstof left a comment

Choose a reason for hiding this comment

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

The new tag must be added in the whitelist of the UnusedTags pass, to avoid complaining about this tag not being during the container building.

return$builder->getAlias($serviceId);
}

if ('service_container' ==$serviceId) {
Copy link
Member

Choose a reason for hiding this comment

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

should use a strict comparison

@nicolas-grekas
Copy link
MemberAuthor

Replaced by#26921

fabpot added a commit that referenced this pull requestApr 20, 2018
… a dot (nicolas-grekas)This PR was merged into the 4.1-dev branch.Discussion----------[DI][FrameworkBundle] Hide service ids that start with a dot| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | yes| Tests pass?   | yes| Fixed tickets |#26630| License       | MIT| Doc PR        | -Now that services are private by default, `debug:container` should display them by default.In fact, the public/private concept should not trigger a difference in visibility for this command.Instead, I propose to handle service ids that start with a dot as hidden services.PR should be ready.(For reference, I tried using a tag instead in#26891, but that doesn't work in practice when working on the implementation.)Commits-------cea051e [DI][FrameworkBundle] Hide service ids that start with a dot
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@weaverryanweaverryanweaverryan left review comments

@stofstofstof left review comments

Assignees

No one assigned

Projects

None yet

Milestone

4.1

Development

Successfully merging this pull request may close these issues.

4 participants

@nicolas-grekas@weaverryan@stof@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp