Download the PHP package solventt/slim-route-strategy without Composer
On this page you can find all versions of the php package solventt/slim-route-strategy. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package slim-route-strategy
Table of contents
1) Requirements 2) Installing 3) Flexible controller signature 4) Features 5) Resolving DTO 6) Use cases 7) Writing custom rules
Package is an implementation of a route invocation strategy for the Slim microframework. It allows to flexibly set up resolving of your controller parameters. About the invocation strategy you can read in the Slim docs.
Requirements
- PHP 7.4+ or 8.0+
- Slim microframework version 3+ or 4+
- any DI container. But if it has no autowiring, and will not affect the resolving of controller parameters.
Installing
Flexible controller signature
By default, Slim controllers have a strict signature: , ,
And so you can't omit any of these parameters even if one is not needed. It is called the strategy.
But with this package:
- you may specify any parameters you need and even an empty controller signature
- the order of the parameters doesn't matter
- services will be injected by type-hint
- in addition to the route placeholders you also can receive request attributes and Data Transfer Objects (instead of the POST/PUT/PATCH arrays) in your controller parameters
- incoming parameter will have integer type instead of default string type (optional)
- you can add your own parameters resolving functionality, for example, instead of the parameter you may receive some entity (User)
Features
The route strategy consist of the following rules:
1) IdIntegerTypeRule (optional) - casts string type of the 'id' route parameter (if exists) to integer type. It's especially conveniently while using declare(strict_types=1)
NOTE: the name of the controller parameter and the route placeholder MUST be .
2) FlexibleSignatureRule - tries to map an associative array of route parameters to the controller parameters names.
Assume there is the controller method:
And there are the route parameters:
Then controller method will receive next parameters values:
NOTE: the names of the controller request/response parameters MUST be and accordingly.
3) TypeHintContainerRule - injects type-hinted controller parameters using the DI container. But the union types will be ignored.
4) NullTypeRule - if a controller parameter does not have a default value, it checks presence of the 'null' parameter type and (if successful) take it for resolving:
5) MakeDtoRule - read the next section.
By default, only , and are active.
Also, you can add your own rules.
Resolving DTO
converts a data array of POST|PUT|PATCH requests into a Data Transfer Object (DTO)
By default, it will be created the built-in Dto class filled with the request data. But you can define your own DTO class and your own logic for processing the data and filling the object with it, using factories.
Example
Definition for the DI Container:
Factory logic:
And the controller method:
REMEMBER: 1) Name of the parameter must contain a 'dto' substring. For example: '$userUpdateDto', '$dto', 'myDto', 'loginDto' and so forth. 2) You need to specify a parameter name in the DI Container definition as an array key. The value of the array - a corresponding DTO factory class. 3) The DI container definition must be named as 'dtoFactories' (see the example above).
Use cases
For Slim version ^4.0, :
For Slim version ^3.0, :
About the strategy rules
If you don't provide any rules to the rout strategy constructor, only FlexibleSignatureRule
, TypeHintContainerRule
and NullTypeRule
will be enabled by default.
For example, you want to add and , then you should define all necessary rules explicitly:
Or if you want to add only a rule:
REMEMBER:
- the rules must be specified as existent class strings
- the rules order matters. E.g. if you define after . Then will have no effect - the type of the will be string instead of integer.
The example above shows the correct order of the rules.
Writing custom rules
Your custom rule must implement .
Let's look at the simple example. Suppose you want the controller method to receive the User entity as an argument. So the route is:
The controller method is:
And you wrote your custom :