The ADR triad is not meant to be implemented in an agnostic way, but rather implemented exactly as necessary for each use case. This makes general purpose responders pointless, since the responder attached to each action (or possibly groups of actions) will generate an exact response based on the requirements of the use case.

Refs #75

This change will allow the use of prepared objects of middleware.

Now ResolverTrait::resolve method does not check for object and fully trust a conctrete implementation of ResolverInterface. (I hope it will not affect performance) So now any Resolver must return the object back when an instance already exists.

I guess for this case we need to have a test.

Currently, if an acceptable response content type cannot be determined, the first available formatter is used.

From section 12.2 of RFC 2616:

HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using server-driven negotiation.

It seems like we should be returning a 406 response code in that scenario instead.

According to the intent of ADR, the Action part of the triad is meant to be a completely custom class that provides a boundary between HTTP and domain logic. The action is aware of the domain and knows how to direct output through a responder.

This is not how Equip has been treating the domain. Our attempts to make Domain pseudo-HTTP-aware with Payload and Input has not been very successful and is probably the least concise bit of the framework.

This stems from a gist I made some time ago as a proof of concept.

TODO

• [x] update documentation
• [x] decide what to do with responders
• [x] delete equip/adr dependency (?)

PHPUnit >= 5.2 requires PHP 5.6, but the Equip still supports PHP 5.5 (Travis CI) PHP 5.5 is no longer supported, so it should be removed from the builds.

Now, every build has the warning that the TestCase::getMock method has been deprecated.

Ref: equip/auth/pull/3

My attempt to remake the (Whoops) ExceptionHandler. These changes have a huge impact on performance. (less reponse time) But it's still work in progress, I have a proposal that may affect the final result.

I used the Whoops handlers as a formatters, which are used a generic Responder like FormattedResponder and DTO Payload. That seems the obvious way, and does not violate the ADR pattern:

Action-Domain-Responder: View vs Responder

Note also that a generic Responder may be used by more than one Action. The point is that the Action leaves all header and content work to the Responder, not that there must be a different Responder for each different View.

My suggestions To make an interfaces for exceptions, it's a sketch:

use Equip\Exception\ExceptionInterface;
interface EquipExceptionHandlerInterface
{
    public function __invoke(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next
    );
    public function withEquipException(ExceptionInterface $exception);
}

use Exception;
interface ExceptionHandlerInterface
{
    public function withException(Exception $exception);
}

use Throwable;
interface ThrowableHandlerInterface
{
    public function withThrowable(Throwable $throwable);
}

Use a PSR logger as a decorator. Soon I'll add it. Use the Whoops as a separate package. It already looks like that. Use for the Equip a simple (native) exception handler by default, and change it using a DI.

use Equip\Exception\ExceptionInterface;
use Exception;
public function __invoke(
    ServerRequestInterface $request,
    ResponseInterface $response,
    callable $next
) {
    try {
        return $next($request, $response);
    } catch (ExceptionInterface $exception) {
        return $this->exceptionHandler->withEquipException($request, $response, $exception);
    } catch (Exception $exception) {
        return $this->exceptionHandler->withException($request, $response, $exception);
    }
}

Response body formatting should not be tied to status, as it prevents having responses with no body. For example, a 204 No Content response without a body is perfectly acceptable.

Fixes #34

Refs equip/structure@9bb7222d9570

~~Since the method names have changed, this will need to be released in v2.x.~~ Added a compatibility trait to ensure backwards compatibility.

I'd like to be able to use the core configuration code (i.e. ConfigurationInterface and ConfigurationSet) apart from the rest of the framework. I think there may be sufficient value in this notion to warrant moving it to its own repository.

It's under its own sub-namespace, so no namespace changes would be needed. The only potential difficulty I can see that it introducing is that any major version upgrades to equip/structure dependency would have to be done on both repositories simultaneously to avoid version conflicts.

Rather than having a single large routing table, split routing into separate dispatching classes, similar to a middleware set.

See MIGRATING.md for how it would look to users.

As title, is this project still maintain?

It seems that this project has been inactive for about whiles.

Once this project status is on maintained, let me do some contributions on that to keep this package better :).

equip/framework now has a Chat Room on Gitter

@ameech has just created a chat room. You can visit it here: https://gitter.im/equip/framework.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.