Every handler needs to inject the config even if is not needed

[cPintiuta]

Every new handler needs to inject the config in order to work, even if you create a simple handler for outputing a simple get response.
This is because the method isGetCollectionRequest from HandlerTrait request it.

I think this is related to #269

[arhimede]

what if we ask @Xerkus to give his opinion in this matter ?

[Xerkus]

config in the handler is messed up. Deprecate and get rid of it.

Those handler traits are problematic from code quality perspective. It would be good to get rid of them as well. Move them into injectable dependencies.

I am cloning the repo and will take a closer look.

[alexmerlin]

config in the handler is messed up. Deprecate and get rid of it.

Config in handle has only one purpose: to find out if a GET request is for a single item or a collection of items.
I was thinking of a middleware that would identify this so in HandlerTrait::handler method I would use this new value and then I could remove the config from all handlers.

Those handler traits are problematic from code quality perspective. It would be good to get rid of them as well. Move them into injectable dependencies.

Why are they problematic? They are just as easy to test as a handler.

I am cloning the repo and will take a closer look.

I'm curious to see your findings. :)

[Xerkus]

Handler being aware of config structure, of metadata map and its structure is a sever violation of single responsibility principle.

Extract the isGetCollectionRequest into an interface + concrete implementation, register that in container and inject in place of the config as a regular dependency. It will massively simplify the handler.

Better yet, I would recommend to abandon the approach of handling the resource and its collection in the same handler.
They require different urls and respond differently to the http methods. Split into separate handlers and there won't be a reason to perform isGetCollectionRequest check in the first place.

I personally prefer to separate get and post/patch/delete actions further into separate handlers. It makes middleware pipes so much more powerful with a simple composition.

For the response trait I would also recommend to extract it into an object in its entirety and inject it as a dependency. It can be improved by utilizing PSR-17 factories and further improved by the use of Mezzio\ProblemDetails\ProblemDetailsResponseFactory. RFC 7807 problem details response is far superior to any custom error response.

[alexmerlin]

Better yet, I would recommend to abandon the approach of handling the resource and its collection in the same handler.
They require different urls and respond differently to the http methods. Split into separate handlers and there won't be a reason > to perform isGetCollectionRequest check in the first place.

We elliminated the config dependency from all handlers by moving collection-related code to different handlers.
Each resource (Admin, AdminRole, User, UserRole) has it's own collection handler implementing the get method which returns a collection of the requested resource.