This PR is to make #189 smaller and easier to read. This PR is also back compatible with other modules such as JSON::Validator::OpenAPI::Mojolicious.
Motivation
I think it's necessarily to split the functionality of JSON::Validator into separate schema classes to reduce the cost of maintaining the code for the new JSON-Schema drafts (and OpenAPI specifications. This PR is just the first step in that direction. Right now, we are getting more and more if/else branches such as if ($jv->version == 6) to run the correct logic for a given schema. I think creating a new JSON::Validator::Schema sub class will make it easier to read and understand the code.
The next step, without considering #189, would be to allow all the schema objects to be part of a shared pool, so if J::V creates a couple of schema objects, then they should be able to reference each other. I think this is pretty much done internally with $self->{schemas}, but it needs to be exposed in a nice way to the user.
Summary
This PR is to make #189 smaller and easier to read. This PR is also back compatible with other modules such as JSON::Validator::OpenAPI::Mojolicious.
Motivation
I think it's necessarily to split the functionality of JSON::Validator into separate schema classes to reduce the cost of maintaining the code for the new JSON-Schema drafts (and OpenAPI specifications. This PR is just the first step in that direction. Right now, we are getting more and more if/else branches such as
if ($jv->version == 6)
to run the correct logic for a given schema. I think creating a new JSON::Validator::Schema sub class will make it easier to read and understand the code.The next step, without considering #189, would be to allow all the schema objects to be part of a shared pool, so if J::V creates a couple of schema objects, then they should be able to reference each other. I think this is pretty much done internally with
$self->{schemas}
, but it needs to be exposed in a nice way to the user.References
189