[
https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206632#comment-14206632
]
Ramesh Reddy commented on OLINGO-482:
-------------------------------------
+1, I like this proposal over the current model of static Processor interfaces.
Few reasons, I see are
- It makes the service development easier, as developer need to focus only
services's business logic. However this will create much more finer grained API
- Takes building of "context-url" out of the hands of service developer to
framework developer. Which is good, as framework Olingo API needs to provide
this. I know I mentioned this before on some other JIRA
- Serlialization efforts are moved from service developer to frame work
developer. This is good as, Olingo can enforce the "accetps" or "$format"
choices away from un-informed service developer.
In the current Processor interfaces, the "type" of the interface along with
"method" name indicated which kind of request it was, in this proposal that
information is lost. However, that can be easily captured by deriving the
ODataRequest to be in the form of like "EntitySetRequest", "EntityRequest",
"FunctionRequest", "ActionRequest", "CountRequest" etc. The matrix of request
and return should form the complete invocation APIs.
[~mirbo] have you started any work on this? I have not contributing any code
based on this proposed change. Let me know, how I can help.
> 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
>
> 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)
