Skip to content
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

Remove Navigation View Helpers #259

Open
wants to merge 1 commit into
base: 3.0.x
Choose a base branch
from

Conversation

gsteel
Copy link
Member

@gsteel gsteel commented Nov 25, 2024

Q A
Documentation yes
BC Break yes

Description


As such, the namespace for these helpers has changed from `Laminas\View\Navigation` to `Laminas\Navigation\View\Helper`, so if you have referenced the FQCNs of these helpers in your code, you will need to update them accordingly.

At the time of writing, the `laminas-navigation` 2.x series of releases is not compatible with `laminas-view` 3.x and a major release of the `laminas-navigation` component is not available.
Copy link
Member

Choose a reason for hiding this comment

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

Would it help or be easier if we moved the helpers to a separate package? The original plans included the support of different template systems, laminas-view would be one of them.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure it'll be easier, but it would make evolution of all 3 libs easier in the long-run.

The problem here is the appetite to maintain them. As they stand, there is a lot that needs improvement and refactoring with the old helpers, so, assuming we move them to a new lib instead, will it be acceptable to have a v1 release that is largely the same as they are now, warts and all, or is there an expectation they'd be polished up a bit for a view v2 compatible release?

Additionally, what would the lib be called and what would the NS be? Laminas\NavigationView?

Copy link
Member

Choose a reason for hiding this comment

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

…but it would make evolution of all 3 libs easier in the long-run.

That was the idea.

…will it be acceptable to have a v1 release that is largely the same as they are now…

That would probably be the quickest option.

…or is there an expectation they'd be polished up a bit for a view v2 compatible release?

You mean version 3 of laminas-view?

Additionally, what would the lib be called and what would the NS be? Laminas\NavigationView?

The original idea was that the HTML would be created by the laminas-navigation component and then there would be simple integrations in different template systems. laminas-view is one of them and then Plates, Twig, etc. – like we have in Mezzio.
So it could be laminas-navigation-laminasview, laminas-navigation-twig, …

Copy link
Member Author

Choose a reason for hiding this comment

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

…or is there an expectation they'd be polished up a bit for a view v2 compatible release?

You mean version 3 of laminas-view?

I meant here, that we'd likely want to release v1 of nav-view to be compatible with view v2 so there is an easy upgrade path - it will need a major release to support SMv4, so nav-view v2 would be compatible with view v3 and SMv4

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

Successfully merging this pull request may close these issues.

2 participants