Hi Michael,
Thanks very much for your answer! I understand well your approach and I agree
that the library stability is the most important thing. I think however that
it's great that such works like the Ramesh's one to simplify the service
developer life are done in parallel by the community. ;-)
Thierry ______________________________________________
-- Take a look at my blog: http://templth.wordpress.com/
Le Vendredi 20 février 2015 14h32, mibo <[email protected]> a écrit :
Hi Thierry,
I’am also a friend of a more framework like approach, at least as a service
developer.
And your ideas with using Java annotations sounds also nice and promising (and
remember me a little bit at the Java annotation PoC in Olingo v2 and
OLINGO-129).
But I also think that for Olingo 4.0 and the first stable core release focus
should be on implementation of OData Version 4 specification in a more library
point of view.
Afterwards if the library is stable and supports the main OData 4 specification
aspects the next steps could be to do more for the convenience of a service
developer with frameworks on top of the library (e.g. JPA and Java-Annotation
extensions in Olingo V2).
But this is just my current opinion and focus and I will not prevent anybody in
the community to start with a framework around of Olingo. Quite to the
contrary, I think it's good when proof of concepts and/or frameworks already
are started ;o)
Back to OLINGO-573 I think we should check if the processor design is an
approach which should/could be merged into the core (or replace actual design)
or if it is the better way to see it as a framework/extension which resides on
top or beside the core library.
Because at least with the next „beta-03“ release we should be stable with the
API (just smaller changes but not a greater redesign).
And for your questions, for me it is ok to discuss/comment in the issue. So
feel free to put your mail in OLINGO-537.
And the TripPin service is implemented in the „TripPinHandler“ and
„TripPinServlet“ classes within the test module (packages), so you have already
found it ;o)
Kind regards,
Michael
> On 20 Feb 2015, at 11:45, Thierry Templier <[email protected]> wrote:
>
> Hi Michael and Ramesh,
> I definitively love such approach. It's clear that we need to use some
> "plumbing code" to implement OData applications with Olingo. I agree and also
> think that most of them can be integrated in Olingo itself and not use
> directly by the service developer. Having such processor interfaces (the
> Ramesh's ones below) are really valuable and are in the spirit of a framework
> approach rather than a library one. I think that we don't need in most cases
> to work on OData request and response objects of Olingo. This will contribute
> to reduce the amount of code and the complexity of processors.
> EntitySet readEntitySet(EdmEntitySet es, UriInfoResource uriInfo)EntitySet
> readEntitySet(EdmFunction ef, UriInfoResource uriInfo)long
> readCount(EdmEntitySet es, UriInfoResource uriInfo)
>
> However I wonder if we could go a bit further than static interfaces. Some
> frameworks (like Spring MVC / REST) leverages an approach where the method
> signatures to handle requests aren't static. The service developer is free to
> choose which parameters he wants to have. Such methods are defined and
> configured using annotations. I find this approach very valuable, flexible,
> convenient and efficient since it allows to get the hints you need very easy.
> For example, we can have:
> @RequestMapping(method = RequestMethod.GET)public Map<String, Appointment>
> get() { (...) }
> @RequestMapping(value="/{day}", method = RequestMethod.GET)public Map<String,
> Appointment> getForDay(@PathVariable @DateTimeFormat(iso=ISO.DATE) Date day,
> Model model) { (...) }
> @RequestMapping(method = RequestMethod.POST)public String add(@Valid
> AppointmentForm appointment, BindingResult result) { (...) }
> In the context of OData / Olingo, we could have something like that to
> implement processors.
> @Processorpublic class MyProcessor {
> @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY_SET)
> public EntitySet readEntitySet(EdmEntitySet es, UriInfoResource uriInfo) {
>(...) }
> @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY_SET) public
>EntitySet readEntitySet(EdmEntitySet es, ODataRequest request) { (...) }
> @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY) public Entity
>readEntity(EdmEntitySet es, @KeyPredicates List<URIParameter> keys) { (...) }
> @ProcessorMethod(type = ProcessorMethodKind.UPDATE_ENTITY) public
>Entity updateEntity(EdmEntitySet es, Entity entity, @KeyPredicates
>List<URIParameter> keys, HttpMethod method) { boolean partial =
>request.getMethod().equals(HttpMethod.PATCH); (...) }}
>
> This would be a layer upon the classic approach and / or the Ramesh's one.
> This also would bring auto-detecting and auto-configuration (based on
> annotations) of processors against the OData HTTP handler.
> Notice that the field type in the annotation could be easily deduced from the
> method signature in most cases.
> Otherwise honestly I can't find the TripPin service in the branch
> olingo-server-extension:
> ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinHandler.java
> ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinServiceTest.java
>
> ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinServlet.java
>
> Can you give me more hints to find out this sample? Thanks!
> Thierry
