-
Notifications
You must be signed in to change notification settings - Fork 56
split a simpler json-schema validator from the route-based-validator #46
Conversation
this is preliminary work. i need to update documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi. I gave you some feedback :)
@@ -30,31 +29,15 @@ public function __construct(array $schemas) | |||
* | |||
* @return ResponseInterface | |||
*/ | |||
public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next) | |||
public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$next
cannot be null
, this argument is mandatory.
* @throws \InvalidArgumentException | ||
* @throws \JsonSchema\Exception\ExceptionInterface | ||
*/ | ||
public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As said before, $next
is required
json_encode($validator->getErrors(), JSON_UNESCAPED_SLASHES) | ||
); | ||
$validator = new JsonValidator($schema); | ||
$response = $validator($request, $response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this middleware is the same than JsonValidator
but handle multiple schemes, once the scheme has been choosen, why not simply execute the following?
return $validator($request, $response, $next);
@oscarotero thanks for the review! i've added a new commit to require $next. this enforcement allowed me to remove two branches in the validator middlewares. i still need to add documentation, and when this is all done i will squash the commits. how does the latest change set look? |
…imple validator handles a single schema and there is no route-based logic. the file-per-route implementation consumes the simple validator. corrected some false-positives in the json-schema tests.
@oscarotero updated docs. i think my change set is stable, unless you have some other feedback. let me know if the changes to the json-schema test make you nervous. i can split this request. i noticed that there were some false positives, and i had forgotten to update the test's assoc config after we renamed it : / |
]), | ||
|
||
// Specify a JSON file (publicly-accessible in this example), or a JSON string decoded into object-notation. | ||
Middleware::jsonValidator((object) [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're pushing quite a bit of implementation detail to the middleware definition here... I'd prefer to just push a reference to a file (either SplFileObject or a string to the path), rather than deal with the specifics of how the chosen Schema Validator needs to receive the schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great point. the implementation uses justinrainbow/json-schema, which can accept a file ref or a decoded schema. so your validator factory could create a schema inline, without using any files or file ops. do we really want to enforce file only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, i could create a couple of named factories, one for a decoded object, and another that accepts SplFileObject (great suggestion).
'forceArray' => false, | ||
]), | ||
|
||
// Specify a JSON file (publicly-accessible in this example), or a JSON string decoded into object-notation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment does not match the method signature... the case of specifying a file is not supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the underlying lib accepts the ref as an object, e.g.
(object) [
"$ref" => "path/to/schema.json",
]
[ | ||
'Content-Type' => 'application/json', | ||
], | ||
json_encode($validator->getErrors(), JSON_UNESCAPED_SLASHES) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're assuming the API will be providing a JSON response here, which is not necessarily true for all cases, even if we're in the business of receiving JSON. I'd be very surprised as a developer if a middleware layer suddenly decided to switch the content-type around. Think for example about people using JSON-API, which specifies a content type of Content-Type: application/vnd.api+json
.
@oscarotero Does the project have a "best practice" way of dealing with generating responses to match the Accept headers provided by the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the response generation can be configured in a similar way than errorHandler or shutdown, providing a callable handler:
$errorResponse = function ($request, $response) {
$validator = JsonValidator::getValidator($request);
$response = $response->withHeader('Content-Type', 'application/json');
$response->getBody()->write(json_encode($validator->getErrors(), JSON_UNESCAPED_SLASHES));
};
$middlewares[] = Middlewares::JsonValidator()->errorHandler($errorResponse);
And if no custom errorHandler is provided, use the default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok thanks, i'll try this out. great suggestions @sbol-coolblue and @oscarotero .
…stronger API. creation of the validator by file or json string (for example) is more obvious. updated docs.
Thanks for the improvements - really appreciate them. |
@sbol-coolblue no problem! i really appreciate the feedback. my builds are failing right now because of some issue with the composer dependency versions. i'll get it working and then we can all discuss. also, i still need to update the error handler. i haven't forgotten. |
@sbol-coolblue @oscarotero i made some changes based on your feedback last week. the build failed because a composer dependency was not able to be installed. see the build output: i was able to resolve by changing i'll also update the error handler this week : ) |
Running into the same issue. I'll create a PR for the fast-route change. |
Oops!! I've merged this by mistake. |
@oscarotero you got click-happy! yes it's not a problem at all. i think the error-handler changes can be done in a compatible fashion. do you mind holding off on the tag until i can complete this work? would take the pressure off of me haha. |
Don't worry. I have not planned a new release in this week, there are still some things to do. |
no problem. i'll start working on it tonight. do you have a documented release schedule? |
No really, but I'd like to close other issues like #50 before tagging |
split a simpler json-schema validator from the multi-validator. the simple validator handles a single schema and there is no route-based logic. the file-per-route implementation consumes the simple validator.