GitLab

Follow-up 5182ff4293ee

pyramid.predicates.AcceptPredicate handle both single and multiple values now
https://github.com/Pylons/pyramid/blob/0c29cf2df41600d3906d521c72991c7686018b71/src/pyramid/predicates.py#L138

self.val has been renamed to self.values

Previously, we did "request.json_body" in every data submission views
(like entity creation or update, with HTTP method being POST or PUT).
This instruction might fail with JSONDecodeError exception if the body
fails to JSON decode. This would result in a 500 error response. Rather
we want to return a 40x response indicating that this is a client error.

So we now raise a 415 Unsupported Media Type error through a
_json_body() helper function every times we need to decode JSON body of
incoming requests. Notice that since json module only has
JSONDecodeError exception on Python3+, we catch ValueError on Python2.

A functional test is added for entity creation view.

We define interfaces (using zope.interface) for main resource classes
and refer to these interfaces (as dotted names) in API views' context
instead of registering these views against the resource classes
directly.

The idea is to make it possible for downstream applications to register
their own resource classes that could be selected by standard API views.

Interfaces have attributes and methods declared based on what appears to
be needed on API views. We use interface inheritance to reduce
duplication (e.g. the IMapped interface is a base for all interface but
IRoot; IRelatedEntities is a base for IRelatedEntity).

Notice that this somehow conflicts with the Mappable abstract class that
was defined previously in resources module; so we drop this abstract
class and replace it by an IMapped interface.

Instead of assuming that the context resource in get_entities() view has
an "etype" attribute (which won't be true anymore in next changeset), we
delegate permission check to the resource object in the form of an
has_perm() method. This is step towards defining abstract interfaces for
resource classes.

I'm getting into trouble while trying to reuse this class in a multiple
inheritance context because the proper __init__ method is never called.
So, let's get rid of __init__ in Paginable and implement 'limit',
'offset' and '_has_next' attributes, previously defined in __init__ as
reified properties. Notice that, since _has_next may be changed (in
paginate() method), we also need a setter for this property.

Accordingly, drop super() calls in resource classes inheriting from
Paginable and mention that this class should be used as a mixin.

This is useful for representing collection of heterogeneous entities.

This mapper would be selected by its regid only, with no extra argument
in contrast with other 'jsonschema.collection' mappers that either
accepts an "etype" parameter or a relation context. This mapper does not
handle submission (i.e. entity creation) since the target entity type is
unspecified; so we return a "false" JSON Schema for "creation" role.

In tests, we rename prior test case CollectionMapperTC as
EntityCollectionMapperTC and add back a CollectionMapperTC explicitly
testing the new mapper class.

And make the error message a bit more explicit.

Closes #17103219.

This is how yams_match predicate expects it.

When non-ASCII characters are present in "links" data, the previous
code (as it used bytes for string formatting) would try to encode this
data and may thus fail with a UnicodeEncodeError. To prevent this, we
use unicode string when formatting links parameters (i.e. add a u''
prefix). Nevertheless, we must still return a "native" string for
validity with WSGI specification (this is either bytes on Python 2 or
unicode string on Python 3):

  https://www.python.org/dev/peps/pep-3333/#a-note-on-string-types
  https://docs.pylonsproject.org/projects/webtest/en/latest/api.html#module-webtest.lint

Added regression tests accordingly.

Only RemoteCallFailed has an attribute called "reason", which is also the
message of the exception.

Use str() to have a compatible way to get the error message.

A JSON Schema must be a Boolean or an object.

For such values, we do not add the $schema property.

This renderer is defined in
cubicweb_jsonschema/api/schema.py:includeme().

Previously, we no transition was possible to fire, we would return an
empty array in the "oneOf" of "name" property, which is invalid (see
https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-6.7.3).

So we return a "false" Boolean schema in these cases, thus clearly
indicating that no transition can be fired.

This view will be selected upon any exception which is a subclass of
cubicweb.web.RequestError when the request has Accept:application/json.
Previously, the "generic_error" view would have been called, but it
cannot accurately handle CubicWeb's web exceptions (it always returns
500, whereas these web exceptions may have a different status code).

Why are these views selected? This is because the RootResource matches
for any request with this Accept:application/json header. (In fact, we'd
want to use this error view only when the request comes from a
sub-resource of the RootResource; but that's not easy to achieve.)

So this new error view convert a cubicweb.web.RequestError into an
application/problem+json response. This is thus not backward compatible
with what CubicWeb would return.

In added test, we use the "format_date" "ajax" controller (of CubicWeb)
with missing argument which then responds with a RemoteCallFailed (with
a 500 status) that is called by our view.

CubicWeb's Predicate's __call__ method's interface is:

  def __call__(self, cls, req, **kwargs):

In yams_match, we had 'rtype' and 'role' as non-keyword arguments, thus
producing TypeError upon calls of a class's __select__ without all
required arguments. We change this to have 'rtype' and 'role' option
(though score will still be 0 if they are unspecified) so that we now
respect base interface.

`etype_mapper` is not appropriate since the mapper bound to
ETypeResource is actually a "jsonschema.collection" mapper.

We introduce a assert_jsonschema_validate() helper function to reduce
code duplication.

Prior to introduction of CompositeRelationItemMapper in previous
changests, serialization of items of a composite relation that is not
inlined did not work. By making use of plain "jsonschema.item" mapper
for targets of such relations we make this possible.

We here add unit tests in test_mappers.py along with a functional test
in test_api_misc.py.

This mapper has "jsonschema.item" regid, so it belongs to
mappers.collection module. We also rename it changing "inlined" into
composite since this is was it is (see selector). Since we lost the base
class we have to re-implement selection argument parsing and setting as
attribute, hence the new __init__ method.

It's probably not meant to be part of the public API but I need it
downstream at the moment.

Instead of duplicating the logic of serialization of items in this
method, we now rely on a dedicate "jsonschema.item" mapper (properly
selected with relation information) to serialize each item of the
relation.

Previously, the set of related entities was computed within
"jsonschema.relation" mappers and their serialize() method accepted only
the main "entity" from which this "related" set was computed. This is
asymmetric with "jsonschema.collection" which serialize() method handles
a list of entities. So we make the former mappers accept the set of
related directly as an argument to their serialize() method. This set is
computed by "jsonschema.entity" mapper.

This is a step forward merging "jsonschema.relation" mappers (for
non-final relation) with "jsonschema.collection" mappers.