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

Deprecate injection of assets based on controller/action. #98

Open
Thinkscape opened this issue Nov 12, 2013 · 1 comment
Open

Deprecate injection of assets based on controller/action. #98

Thinkscape opened this issue Nov 12, 2013 · 1 comment

Comments

@Thinkscape
Copy link

At first, I was happy and keen to rely on automatic injection of assets depending on the controller/action. However after some time using it, I've found it's prone to a lot of errors.

Because of the nature of zf2 mvc and modules interacting with the request flow, the injection is very fragile. For example, errors will cause the request to be handled by error controller, however the mod has already decided to use assets from the non-existent page. Another example would be any access-control modules, which deny access or forward depending on some conditions - this also confuses the mod.

The only safe way to handle this is to rely on explicit inclusion of resources. Because resources belong to the rendering/view phase, they should live there - so the perfect place would be a view helper, or resolver attached to a view helper. In any case, the inclusion must happen at rendering/view phase, not dispatch.

There's also the case of flexibility - current "matchers" only work on controller and action names. It is not possible to branch the inclusion logic inside controller and/or view script. If we had explicit inclusion then one could include any resources based on any requirements (be that in controller, layout, page view script or some listener).

@widmogrod
Copy link
Owner

Very good point.
If you create pull request with such changes I will merge it.
But very important is to maintain back compatibility.

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

No branches or pull requests

2 participants