Conversation
9b0720b to
97815a4
Compare
thijslemmens
left a comment
There was a problem hiding this comment.
As discussed.
Untangle the PropertyRestController from real controllers.
Move the controller mappings to EntityController. Use Factory + Strategy pattern for the different implementations (relation, content, normal property) ...
40267c9 to
1e224da
Compare
...st/src/main/java/com/contentgrid/appserver/rest/property/handler/RelationRequestHandler.java
Outdated
Show resolved
Hide resolved
...st/src/main/java/com/contentgrid/appserver/rest/property/handler/RelationRequestHandler.java
Outdated
Show resolved
Hide resolved
rschev
left a comment
There was a problem hiding this comment.
Personally, I think this has more indirection and complexity than we need. If someone new is reading the code, and they find the PropertyItem- or PropertyRestController, it's not clear at all which things handle these endpoints, and in what order. They'd have to start looking through the codebase for things that implement these Handler interfaces, but then that's an abstract class, you have to find what extends this abstract class, and then you still don't know what order these things are tried in.
It might have been a bit more "wordy", but I would have preferred to read, right in the restcontroller, something like:
if (contentPropertyRequestHandler.matches(entityName, property) {
return contentPropertyRequestHandler.handle(entityName, instanceId, property);
} else if (xToOneRequestHandler.matches(entityName, property) {
return xToOneRequestHandler.handle(entityName, instanceId, property);
} else if (xToManyRequestHandler.matches(entityName, property) {
return xToManyRequestHandler.handle(entityName, instanceId, property);
} else {
// return error
}
contentgrid-appserver-domain/src/main/java/com/contentgrid/appserver/domain/DatamodelApi.java
Outdated
Show resolved
Hide resolved
contentgrid-appserver-domain/src/main/java/com/contentgrid/appserver/domain/DatamodelApi.java
Show resolved
Hide resolved
| datamodelApi.findById(application, property.getSourceEndPoint().getEntity(), instanceId) | ||
| .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND, "Entity with id %s not found".formatted(instanceId))); | ||
| var redirectUrl = linkTo(methodOn(EntityRestController.class).listEntity(application, targetPathSegment, 0, | ||
| Map.of(property.getTargetEndPoint().getName().getValue(), instanceId.toString()))).toUri(); // TODO: use RelationSearchFilter |
There was a problem hiding this comment.
RelationSearchFilter doesn't exist any more :)
We'll leave this for a next PR, I guess.
There was a problem hiding this comment.
Now that I see this, I noticed that this throws a NullPointerException when property.getTargetEndPoint().getName() is null
29a1cbb to
cfa48cd
Compare
| mvc.problemdetails.enabled: true | ||
| server: | ||
| port: ${PORT:8080} | ||
| max-http-request-header-size: 10MB No newline at end of file |
There was a problem hiding this comment.
10MB is beefy, I reckon I can now paste the whole Lord of the Rings trilogy in a single header. What prompted this change?
There was a problem hiding this comment.
I copy pasted this from v1 applications. There it was needed because the gateway adds the residual expression from opa as a thunx expression to the jwt token. And those expressions turned out to be beefy. It is definitely not needed for current state of v2 applications, but might be needed later on.
| var targetPathSegment = property.getTargetEndPoint().getEntity().getPathSegment(); | ||
| datamodelApi.findById(application, property.getSourceEndPoint().getEntity(), instanceId) | ||
| .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND, "Entity with id %s not found".formatted(instanceId))); | ||
| // TODO: use FilterName of relation |
There was a problem hiding this comment.
I suppose it's not guaranteed that there is a search filter for this relation... Is this appserver's responsibility, or scribe?
There was a problem hiding this comment.
it's for ticket ACC-2149 to find out how to represent it and how scribe can pass the name of the search filter.
| @@ -0,0 +1,5 @@ | |||
| problemDetail.type.com.contentgrid.appserver.rest.exception.PropertyNotFoundException=https://contentgrid.cloud/problems/not-found/property | |||
| problemDetail.title.com.contentgrid.appserver.rest.exception.PropertyNotFoundException=Property not found | |||
There was a problem hiding this comment.
Any particular reason why this is the only one to get a title?
There was a problem hiding this comment.
The default title just says "Not found", I guess it is not really necessary to override it as long as the details contains a detailed message which property does not exist.
because the remarks are taken into account
Support text/uri-list request body types.
Adds:
- POST /{entityName}/{sourceId}/{relationName} for adding items to *-to-many relations
- PUT /{entityName}/{sourceId}/{relationName} for setting a *-to-one relation
- DELETE /{entityName}/{sourceId}/{relationName} for deleting a relation
- DELETE /{entityName}/{sourceId}/{relationName}/{targetId} for deleting an item from a *-to-many relation
…but different mediaType This is usefull when we want to support file upload with content-type 'multipart/form-data' and '*/*'.
…er and XToManyRelationRequestHandler
…n and UnsupportedMediaTypeException Let them extend ResponseStatusException and UnsupportedMediaTypeStatusException from spring web mvc. So that they will automatically be converted to problem details
|



Add
RelationRequestHandler, it implements the following methods fromPropertyRequestHandlerandPropertyItemRequestHandler:getProperty:GET /{entity}/{sourceId}/{relation}putProperty:PUT /{entity}/{sourceId}/{relation}postProperty:POST /{entity}/{sourceId}/{relation}deleteProperty:DELETE /{entity}/{sourceId}/{relation}getPropertyItem:GET /{entity}/{sourceId}/{relation}/{targetId}deletePropertyItem:DELETE /{entity}/{sourceId}/{relation}/{targetId}Add
PropertyRestController, it manages all property endpoints (/{entity}/{id}/{property}) and delegates to the correctPropertyRequestHandler:PropertyRequestHandlerdoes not find the property, it throws aPropertyNotFoundExceptionto indicate a nextPropertyRequestHandlershould handle the property. If allPropertyRequestHandlerthrowPropertyNotFoundException, the response is a 404 Not Found.PropertyRequestHandlerdoes not understand the media type, it throws anUnsupportedMediaTypeExceptionto indicate a nextPropertyRequestHandlershould handle the property and media type. (Allows to support multiple media types for the same property type by creating multiplePropertyRequestHandlers.) If somePropertyRequestHandlerthrowsUnsupportedMediaTypeExceptionand none of the handlers returns aResponseEntity, it is assumed that the property exists and the response is 415 Unsupported Media Type.ResponseEntity<Object>.PropertyItemRestControlleris similar toPropertyRestController, the only difference is that it manages property item endpoints (/{entity}/{entityId}/{property}/{propertyId})