[
https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291424#comment-14291424
]
Ramesh Reddy commented on OLINGO-482:
-------------------------------------
[~mirbo] This weekend I took stab at the API, (this is work very much in
progress, I wanted to show you before I spent too much into it). Apart from the
what I mentioned above, it also removes lot of boiler plate code from the
service implementation. Please take a look at it and let me know what you
think. Obviously I am willing to make adjustments as we see it we think this is
good design.
I used my git repo for this code
[https://github.com/rareddy/teiid/tree/TEIID-2973/olingo/src/main/java/org/apache/olingo/server/core]
> Refactoring of {{Processor}} interfaces
> ---------------------------------------
>
> Key: OLINGO-482
> URL: https://issues.apache.org/jira/browse/OLINGO-482
> Project: Olingo
> Issue Type: Improvement
> Components: odata4-server
> Affects Versions: V4 4.0.0-beta-01
> Reporter: Michael Bolz
> Assignee: Michael Bolz
> Attachments: processor.png, request_model.png, response_model.png
>
>
> h2. Idea
> During the introduction of the {{RepresentationType}} a discussion has
> started about re-factoring of the {{Processor}} interfaces.
> The new idea is to create an own {{*Processor}} interface for each
> {{RepresentationType}} which then has the according HTTP methods (in form of
> read/write/..).
> As a result we don’t have explicit {{ProcedureProcessor}} because during the
> dispatching the {{ReturnType}} of an e.g. Function is evaluated and the call
> is than processed by the according e.g. {{EntityProcessor}} or
> {{EntitySetProcessor}} or {{SomeOtherProcessor}}.
> For the {{ProcessorInterfaces}} the return type ({{RepresentationType}}) and
> its content is leading (and NOT the format). According to this each return
> type (RepresentationType) results in an own {{*Processor}} Interface with
> methods for the possible HTTP Requests (see Mapping HTTP Request -> Processor
> Method). For some exception the return types should be added as method to an
> existing {{Processor}} Interface.
> As example the {{readPrimitiveAsValue(..)}} method should be added at
> {{EntityProcessor}}. On the other side for the {{countXX(...)}} methods an
> own {{Processor}} should be created because the result is not the content of
> the entity (in a different format).
> h2. Mapping HTTP Request -> Processor Methode
> * HTTP GET -> read_XX(...)
> * HTTP POST -> create_XX(...)
> * HTTP PUT -> update_XX(...)
> ** HTTP PATCH -> update_XX(...)
> * HTTP DELETE -> delete_XX(...)
> h2. Processor Interfaces
> * ServiceDocument - R
> * Metadata - R
> * Error - P rocess
> * Batch - P rocess
> * Entity - CRUD
> * EntityCollection - R
> * Primitive - RUD
> * PrimitiveCollection - RUD
> * Complex - RUD
> * ComplexCollection - RUD
> * Count Processor als
> ** Count - R
> oder
> ** CountEntityCollection - R
> ** CountPrimitiveCollection - R
> ** CountComplexCollection - R
> * Media - CRUD => Create Media at {{EntityProcessor}}
> * -Binary - CRUD-
> * -Value - CRUD- => Added as {{readPrimitiveAsValue(...)}} Methode at the
> {{PrimitiveTypeProcessor}}
> * Reference - CRUD
> * ReferenceCollection - RU\[?\]
> * Difference (Delte/Tombstone) - R
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
