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

[Workflow] DeprecateGuardEvent::setBlocked() method#34466

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

Closed

Conversation

@jgallant
Copy link

QA
Branch?4.4
Bug fix?no
New feature?no
Deprecations?yes
Tickets
LicenseMIT
Doc PR

GuardEvent::setBlocked appears to exist for backwards compatibility. If it is called externally, addTransitionBlocker is called with an 'unknown reason' message, which is difficult to debug. Deprecating setBlocked will help users call addTransitionBlocker instead.

ro0NL reacted with thumbs up emojiro0NL reacted with heart emoji
Copy link
Contributor

@ro0NLro0NL left a comment

Choose a reason for hiding this comment

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

THIS. :)

OskarStark reacted with thumbs up emoji
*/
publicfunctionsetBlocked($blocked)
{
@trigger_error(sprintf('The "%s" function is deprecated since Symfony 5.0, use "%s" instead.','setBlocked','addTransitionBlocker'),E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

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

Since 4.4

Copy link
Contributor

@noniagriconomienoniagriconomieNov 20, 2019
edited
Loading

Choose a reason for hiding this comment

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

Is there a reason to process the string with sprintf and not write directly?

Feature related: « which is difficult to debug « transition blocker was aded after set blocked, and its aims is not for debug but more for end user app human understanding
For debug, i mean technical human, there is a trail logger iirc

@nicolas-grekasnicolas-grekas added this to thenext milestoneNov 21, 2019
@lyrixx
Copy link
Member

lyrixx commentedNov 23, 2019
edited
Loading

Hello@jgallant

Thanks for your first contribution.

Unfortunately, I would like tonot add yet another deprecation. We have a solid upgrade path in Symfony, but deprecation are always boring to fix.

TransitionBlockerList was introduced to be able to attach a nice message from a guard when rejecting a transition to display it to the end user. During this work, I kept thesetBlocked() method to keep the BC and also becauseit is possible to choose to not display a message to the end user.

So Instead of removing thesetBlocked() method, I would instead change the default message to put something much more explicit and easier to debug.

Could you update the PR?

@ro0NL
Copy link
Contributor

ro0NL commentedNov 24, 2019
edited
Loading

i see 2 issues withsetBlocked;

  • the message is implicit, and not obvious to discover its root cause (a better message may help though)
  • the blocker list is implicitly cleared, which is a side effect

For usersaddBlocker($msg, $code) would be much appreciated, as keep doing$event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

or with implicit clear:setBlocker($msg, $code)

@lyrixx
Copy link
Member

or with implicit clear: setBlocker($msg, $code)

I like this proposal

@lyrixx
Copy link
Member

I just looked at the code andsetBlocked(bool $blocked) accepts a bool. So we can not change change it tosetBlocked($msg, $code) without a deprecation notice then BC Break (in SF 6.0).

As I said, I would like to avoid to add another deprecation.

So the best option is to change the default message...

@lyrixx
Copy link
Member

For usersaddBlocker($msg, $code) would be much appreciated, as keep doing$event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

@fabpot What is your position concerning this kind of API? Should we stick to something really explicit, or could we add some shortcuts to make thing easier by hiding the reality. I know you already forbid$definition->addTransition('name', 'from', 'to') to keep$defintion->addTransition(new Transition('name', 'from', 'to')) so I think we should not add theses shortcut, But I understand it could be boring...

1 similar comment
@lyrixx
Copy link
Member

For usersaddBlocker($msg, $code) would be much appreciated, as keep doing$event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

@fabpot What is your position concerning this kind of API? Should we stick to something really explicit, or could we add some shortcuts to make thing easier by hiding the reality. I know you already forbid$definition->addTransition('name', 'from', 'to') to keep$defintion->addTransition(new Transition('name', 'from', 'to')) so I think we should not add theses shortcut, But I understand it could be boring...

@nicolas-grekas
Copy link
Member

->setBlocked(bool, $msg = 'Some default') LGTM

@nicolas-grekas
Copy link
Member

Closing in favor of#34573
Thanks for raising the point.

fabpot added a commit that referenced this pull requestNov 24, 2019
…blocking a transition + better default message in case it is not set (lyrixx)This PR was merged into the 5.1-dev branch.Discussion----------[DX] [Workflow] Added a way to specify a message when blocking a transition + better default message in case it is not set| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| Deprecations? | no| Tickets       |Fix#34466| License       | MIT| Doc PR        |Commits-------169bb2f [Workflow] Added a way to specify a message when blocking a transition + better default message in case it is not set
@jgallantjgallant deleted the deprecate-workflow-set-blocked branchDecember 10, 2019 11:06
@nicolas-grekasnicolas-grekas modified the milestones:next,5.1May 4, 2020
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@OskarStarkOskarStarkOskarStark left review comments

@lyrixxlyrixxAwaiting requested review from lyrixxlyrixx is a code owner

+3 more reviewers

@noniagriconomienoniagriconomienoniagriconomie left review comments

@ro0NLro0NLro0NL approved these changes

@samnelasamnelasamnela approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

5.1

Development

Successfully merging this pull request may close these issues.

8 participants

@jgallant@lyrixx@ro0NL@nicolas-grekas@OskarStark@samnela@noniagriconomie@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp