Preparing fields for better query parameters handling #177
Conversation
I've not yet looked at all the commits but it sounds good overall. A few comments/feedback:
I'll come back to that later. |
I'm not a big expert on the subject, so I will just go with some small questions about implementation:
if(String.class == endpointParameter.getParameter().getType()) { my 2c :) |
Great, will take all these pertinent feedbacks into consideration :-) About |
Took into consideration your remarks |
…kept old constructor for backward compat)
…ty method to identify if we're on guava/java8/no optional type and retrieve underlying type Thus, simplified some RestxAnnotationProcessor methods
…ed parameter alongside its type definition
…oint because later, we will need to build parameter coordinates based on endpoint props (and not matcher one). Note that RestxRequestMatcher is still used in the high level API (on the StdRoute superclass)
…e re-used soon..)
…registry). Its purpose is to map request info to a given target type, from both path and query parameters
… when creating new StdEntityRoute. Note that current code will fail since we didn't provided any mapper implementation yet
…pes on body parameters Main purpose here is to prepare fields to have an homogeneous parameters construction between body content/query param/path param
…y improving checks made : - Path parameters can now be Optionals - Request & Path parameters are now bean validated, like body parameters
…n itself without throwing constraint validation exception It will be useful when checking parameters for validity, even when they are null
…g path & query parameters values, thus allowing to plug more complex mappers in the future Provided simple legacy mapper allowing to map simple String to object using MainStringConverter
…anymore, only requiring param name
…med it to EndpointParamDef
…all to Types.getTypeCanonicalNameFor()
(CoyoteStream.available() was returning 0 on buffered streams) Thus, prefering to catch JsonMappingException to detect null body content
…turns a parameterized type : using MyType<ParameterizedType>.class doesn't work : we must transform it to MyType.class and casting it back to MyType<ParameterizedType> after mapQueryObjectFromRequest()
…data is missing and target type is an iterable
…ndpointParameterMapper* classes into it
… (specific to annotation processor) to AggregateType in restx-common (shared amongst both restx-core and annotation processor)
…hod allowing to know if underlying object mapper knows how to deserialize a given type
…edValuesFor() allowing to retrieve multiple values for a given param name
…tQueryParams(name) when no query param matches given name
…erMapperFactory implementation allowing to bind simple and simple iterable types on query/path parameters. using the same jacksone deserializer as the ones used for BODY deserialization. Note that complex types (=POJOs) are not handled yet
Just rebased my work on I added a bunch of new commits (starting from 36329af) allowing to handle conversions from :
It means that "complex" types (such as POJOs like
To my POV, I consider this PR as finished, but I would be very happy to have some code review from both @xhanin & @a-peyrard to ensure I didn't missed something important. Regarding generated code, only 1 thing was changed compared to my initial PR description : I added an additional
And for
|
Any input for merging this ? :-) |
@xhanin @a-peyrard Except strong disagreement until Wednesday (january 17th), I'm going to merge this PR to integrate it in upcoming release |
This PR makes some refactorings on the codebase to better handle
query & path parameters in the future.
I wanted to implement the issue #146 in multiple phases in order to gather feedback at different checkpoints during the issue resolution.
New things introduced in this PR :
NamedType
which represents a named parameter alongside its type definition (either aprimitive
type or aTypeReference
)Endpoint
class made of a method + pathPattern.Used it in
StdRestxRequestMatcher
in place of the method + pathPatterns fields (kept old constructor for easing / backward compatibility)Not sure if the
Endpoint
naming is nice here (I might rename it to something likeEndpointDescriptor
which is longer, WDYT ?)EndpointParameter
which aggregates both aNamedType
with anEndpoint
to represent a endpoint parameter definitionOptional
(you can haveabsent
values even if I don't really see any workaround for this... this will allow to use a common behaviour between body / query params / path params)String
, primitives,joda times
and so on..) thanks toMainStringConverter
. But later, when we'll support more complex types, it will be useful.Some notes on my work :
lifecycleListener.onEntityInput()
after body content resolution) :MainStringConverter
) prior to callingStdEntityRoute.doRoute()
(this object is passed as adoRoute
argument)doRoute()
implementationOptional
type checks/initialization out of the scope of theEndpointParameterMapper
since it would uselessly complexify the code at runtime whereas we have all theOptional
things available at annotation processing (compile) time.EndpointParameterMapper
/EndpointParameterMapperFactory
thing is not overkill because :joda time
types (for instance) is useless since for this case, I'll rely onMainStringConverter
(thus, if aJackson
deserializer is provided for the target type, it will work out of the box)List
,Array
(etc..) by building some sort of simple ASTMap<String, Either<String,Map,Collection<String>,Collection<Map>>
with provided query / path parameters, then pass thisMap
to Jackson deserializer (which will handle every special cases for me, with nice performances included). In that case I will only have 2mappers
:EndpointRawParameterMapper
(=the current one) andEndpointObjectParameterMapper
(the new one). All I'll have to do is to identify which mapper to use depending on my target type (and here, ok, I'll need to put some pluggability mechanism to say "this type is or is not a raw type")EndpointObjectParameterMapper
implementation, but I'm wondering if we shouldn't simplifyEndpointParameterMapper.mapRequest(EndpointParameter, RestxRequest, RestxRequestMatch, EndpointParameterKind)
prototype (lots of its arguments will be useless)WDYT ?
FYI, following generated
Router
code below :will look like this after this refactoring :