Create new Breadcrumb interface

[core23]

Subject

There is no commen interface for breadcrumbs yet. A breadcrumb must implement a handleContext method.

I am targeting this branch, because this feature is BC.

Changelog

### Added
- Added new `BreadcrumbInterface`

[core23]

We must extend the BlockServiceInterface, because we must pass a valid block service here:
https://github.com/sonata-project/SonataSeoBundle/pull/398/files#diff-eb4c49edd518cf23ec8cccf9141b23f1R69

[wbloszyk]

WDYT about create breadcrumb Block without interface? We can inject menu and menu leaf. Parents road will be new breadcrumb menu. Core menu will work as roadmap.

[core23]

WDYT about create breadcrumb Block without interface?

If I got you right, you prefer an abstract class over an interface? What's the benefit?

We got the actual problem that we overused inheritance for breadcrumbs.

[wbloszyk]

I prefer using one final class with advance configuration. User should inject menu builded on knp-menu. Current uri will tell wich leaf id used. Taking parents we can build breadcrumb.

In PageBundle we can go Evans farder. Create sidemap menu and inject it to this Block.

[core23]

I prefer using one final class with advance configuration. User should inject menu builded on knp-menu. Current uri will tell wich leaf id used. Taking parents we can build breadcrumb.

Can you give an example how this will work with contexts?

At the moment we have many breadcrumbs that are registered. We use the sonata_block_render_event twig function and pass the context to it. Then the listener will decide which breadcrumb is rendered.

[core23]

Please review @sonata-project/contributors

[VincentLanglet]

Breadcrumb lr breadcrumb interface depending on the sonata standard ?

[core23]

Breadcrumb lr breadcrumb interface depending on the sonata standard ?

Do you mean the Interface suffix? AFAIK we have no communicated standard for this.

[VincentLanglet]

Breadcrumb lr breadcrumb interface depending on the sonata standard ?

Do you mean the Interface suffix? AFAIK we have no communicated standard for this.

Yes, there was already a discussion about this and some classes have the suffix but some others doesn’t. It’s a symfony standard but not a communicated sonata one.

That’s why I approved the PR

[core23]

Maybe some other @sonata-project/contributors can give his opinion if we should add technical prefixes / suffixes

[greg0ire]

I find the suffix bad , but I think we mostly use it in Sonata, so to me, the real question is : are we ok with having both? Cause renaming all the existing interface in a BC way would be quite hard I think.

[VincentLanglet]

I find the suffix bad , but I think we mostly use it in Sonata, so to me, the real question is : are we ok with having both? Cause renaming all the existing interface in a BC way would be quite hard I think.

I do like the suffix, and it's commonly used in Symfony. But it's a personal/team choice.

All interface of SonataAdmin have the suffix. I would prefer to be consistent.

[core23]

All interface of SonataAdmin have the suffix. I would prefer to be consistent.

That my be right, but we already support both naming schemas. E.g. this one introduced interfaces without the suffix: sonata-project/SonataFormatterBundle#417

[VincentLanglet]

That my be right, but we already support both naming schemas. E.g. this one introduced interfaces without the suffix: sonata-project/SonataFormatterBundle#417

Yes. Maybe we should decide now if we want to keep supporting both naming.
Or we want to only use one (and then deprecate/renaming in next major the others).

The sooner we decide the less work we will have. @sonata-project/contributors

[greg0ire]

I'd open an issue on dev-kit and link to previous similar discussions in it.

[core23]

I added the Interface suffix, because it's symfony coding standard: https://symfony.com/doc/master/contributing/code/standards.html

[VincentLanglet]

Thanks @core23