Download the PHP package psg/sr2 without Composer
On this page you can find all versions of the php package psg/sr2. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package sr2
Short Description App Standardization
License MIT
Homepage https://github.com/php-sg/sr-2
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package sr2
PSG SR 2 App Standardization
Concepts
Types
- Beforeware : outerware for setting of configuration
- Frontware : middleware caring only about the front
- Middleware : regular middleware the wraps the core and other middleware
- Coreware : the core app logic that is wrapped by middleware
- Backware : middleware caring only about the back
- Afterware : outerware for doing things after the resopnse, like cleaning up
ExitResponseInterface
For Frontware to force a bypass, because it does not control the flow by calling next, it must return a special response implementing ExitResponseInterface. It does this through the app factory $app->createExitResponse, which is just like createResponse.
Request And Response Flow
The above diagram is an oversimplification. The reality looks more like this:
Here you can see that the response is forwarded to the core from the frontware.
Coreware
In Apps, there is an idea of a core which is usually called the controller. What is special about this core is that, regardless of what middleware is added during the running of the app, the core will always be executed at the core (whereas, where middleware is executed depends on the list of other middleware).
I decided to call this core instead of control to make it more generic (it also includes running view code).
I also decided to make this a single callable or {instantiable thing with an __invoke method}. In my implementation, I provide the callable with the parameters ($request, $response, $app). It is, however, expectable that frameworks will want to:
- inject parameters as necessary into the core call
- inject parameters into the __construct if the core is an instantiable As such, the parameters are left up to the framework.
Middleware, like a router, can set the core using $app->core($core). The $app->core() method sets this coreware, and will overwrite anything that exists priorhand as the core.
I decided that the coreware should not be multiple. Coreware is not expected to be generic, it is expected to be specific to the app, so a list is unnecessary.
There is the semblance of a conceptual issue about the has function. Since outerware is now present, and there is front and back specific middleware, what does has refer to?
Extension
Depending on demand and my free time, I will add events and container extensions, probably using the FIG PSRs.
