Download the PHP package rodas/psr-scaffold without Composer

On this page you can find all versions of the php package rodas/psr-scaffold. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

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 PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • 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.
Please rate this library. Is it a good library?

Informations about the package psr-scaffold

PHP Standards Recommendations

This package compiles several PHP Standards Recommendations packages, so they can be loaded using Fallback Autoload or even require_once.

But starting with version 2.0.0, this library has some modifications compared to the original, and with a different namespace, adapted to the new features of PHP 8.4:

This package includes the following PSR libraries and modifications:


The PSRs (PHP Standards Recommendations) are standards recommendations for PHP. They are proposals developed by PHP-FIG, the PHP Framework Interoperability Group, with the goal of improving interoperability between different PHP frameworks and libraries.

Classes, Interfaces and Traits, work of PHP Standards Recommendations, part of The PHP framework interop group

Installation

📦 Available at Packagist: rodas/psr-scaffold > v2.0

PSR Implementations [^1]

These recommendations cover a wide variety of practices and conventions, from coding style to project structuring. TThis repository includes several classes, interfaces, and traits; to cover the following standards:

PSR-03 . Logger Interface

Message

Context

PSR-07 . HTTP Message Interface

HTTP messages are the foundation of web development. Web browsers and HTTP clients such as cURL create HTTP request messages that are sent to a web server, which provides an HTTP response message. Server-side code receives an HTTP request message, and returns an HTTP response message.

HTTP messages are typically abstracted from the end-user consumer, but as developers, we typically need to know how they are structured and how to access or manipulate them in order to perform our tasks, whether that might be making a request to an HTTP API, or handling an incoming request.

Messages

An HTTP message is either a request from a client to a server or a response from a server to a client. This specification defines interfaces for the HTTP messages Psr\Http\Message\RequestInterface and Psr\Http\Message\ResponseInterface respectively.

Both Psr\Http\Message\RequestInterface and Psr\Http\Message\ResponseInterface extend Psr\Http\Message\MessageInterface. While Psr\Http\Message\MessageInterface MAY be implemented directly, implementors SHOULD implement Psr\Http\Message\RequestInterface and Psr\Http\Message\ResponseInterface.

PSR Http Message Util

This repository holds utility classes and constants to facilitate common operations of PSR-7; the primary purpose is to provide constants for referring to request methods, response status codes and messages, and potentially common headers.

Implementation of PSR-7 interfaces is not within the scope of this package.

This package includes the implementations described in the 'fig/http-message-util' package, but alternates the Fig\Http\Message namespace with Psr\Http\Message. Therefore, they are located in the same namespace and folder as the PSR-07 implementations.

Interfaces

PSR-17: HTTP Factories

The purpose of this PSR is to provide factory interfaces that define methods to create PSR-7 objects.

Why Bother?

The current specification for PSR-7 allows for most objects to be modified by creating immutable copies. However, there are two notable exceptions:

StreamInterface is a mutable object based on a resource that only allows the resource to be written to when the resource is writable. UploadedFileInterface is a read-only object based on a resource that offers no modification capabilities. The former is a significant pain point for PSR-7 middleware, as it can leave the response in an incomplete state. If the stream attached to the response body is not seekable or not writable, there is no way to recover from an error condition in which the body has already been written to.

This scenario can be avoided by providing a factory to create new streams. Due to the lack of a formal standard for HTTP object factories, a developer must rely on a specific vendor implementation in order to create these objects.

Another pain point is when writing re-usable middleware or request handlers. In such cases, package authors may need to create and return a response. However, creating discrete instances then ties the package to a specific PSR-7 implementation. If these packages rely on the request factory interface instead, they can remain agnostic of the PSR-7 implementation.

Creating a formal standard for factories will allow developers to avoid dependencies on specific implementations while having the ability to create new objects when necessary.

Specification

An HTTP factory is a method by which a new HTTP object, as defined by PSR-7, is created. HTTP factories MUST implement these interfaces for each object type that is provided by the package.

PSR-18 . HTTP Client

Goal

The goal of this PSR is to allow developers to create libraries decoupled from HTTP client implementations. This will make libraries more reusable as it reduces the number of dependencies and lowers the likelihood of version conflicts.

A second goal is that HTTP clients can be replaced as per the Liskov substitution principle. This means that all clients MUST behave in the same way when sending a request.

Definitions

Client

A Client is an object implementing ClientInterface.

A Client MAY:

If a Client chooses to alter either the HTTP request or HTTP response, it MUST ensure that the object remains internally consistent. For example, if a Client chooses to decompress the message body then it MUST also remove the Content-Encoding header and adjust the Content-Length header.

Note that as a result, since PSR-7 objects are immutable, the Calling Library MUST NOT assume that the object passed to ClientInterface::sendRequest() will be the same PHP object that is actually sent. For example, the Request object that is returned by an exception MAY be a different object than the one passed to sendRequest(), so comparison by reference (===) is not possible.

A Client MUST:

Error handling

A Client MUST NOT treat a well-formed HTTP request or HTTP response as an error condition. For example, response status codes in the 400 and 500 range MUST NOT cause an exception and MUST be returned to the Calling Library as normal.

A Client MUST throw an instance of Psr\Http\Client\ClientExceptionInterface if and only if it is unable to send the HTTP request at all or if the HTTP response could not be parsed into a PSR-7 response object.

If a request cannot be sent because the request message is not a well-formed HTTP request or is missing some critical piece of information (such as a Host or Method), the Client MUST throw an instance of Psr\Http\Client\RequestExceptionInterface.

If the request cannot be sent due to a network failure of any kind, including a timeout, the Client MUST throw an instance of Psr\Http\Client\NetworkExceptionInterface.

Clients MAY throw more specific exceptions than those defined here (a TimeOutException or HostNotFoundException for example), provided they implement the appropriate interface defined above.

PSR-20 . Clock

Introduction

Creating a standard way of accessing the clock would allow interoperability during testing, when testing behavior that has timing-based side effects. Common ways to get the current time include calling \time() or new \DateTimeImmutable('now'). However, this makes mocking the current time impossible in some situations.

Definitions

Usage

References

PSR-03

PSR-07

Http Message Util

Automatic IA Documentation

Ask DeepWiki


[^1]:PSR Implementation versions


All versions of psr-scaffold with dependencies

PHP Build Version
Package Version
Requires php Version >=8.4
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package rodas/psr-scaffold contains the following files

Loading the files please wait ...