[
https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284811#comment-14284811
]
Ramesh Reddy commented on OLINGO-482:
-------------------------------------
[~mirbo] I took some time to look through implementation today, I kind of
understood where you were heading before, but could not foresee any issues
until I wanted to integrate with my project. Please note that criticism is from
eyes of service developer.
* The {{Processor}} interfaces mixed the return types and processing types into
the mixer, thus one sees some not so good fits, like {{BatchProcessor}},
{{CountProcessor}}, {{ErrorProcessor}} etc.
* The ReturnType Processors provide the return of the of request in the name of
the interface, but do not provide any processing side context at all. Thus they
are just more interfaces with more calls, do not provide any real usable
information to a service developer.
* This shifted the Processor interfaces naming from request specific to return
specific. Which is kind of confusing for service developer. The ambiguity of
returning multiple return types only existed in the execution of the
{{Function}} and {{Action}}. To rectify that, now every thing seems ambiguous.
* For me the whole {{Processor}} interface and their sub-categorization and
registration seems verbose. If there is going to be a single {{Processor}}
interface (per category) of given kind for a service, it can as well be a
single simple interface with all possible methods on it. The methods I do not
implement, I can write proxy to say that they not implemented or important for
my service.
* I am not sure the reason behind extended {{Action*Processor}} from their
respective processors? The _Action_ requests ever execute only _invoke_ that
can return a property, list of properties, entity or list of entities or
nothing. It is allowed only for POST. Even though it can be used to
create/update/delete of entities or properties the intent of the invocation can
never be parsed out of the action import's name, so it is up to the service
developer what the POST invocation really means. Thus it not required to have
all inherited methods.
* In same way I am not sure why you wanted to use _Function_ execution to use
different types {{Processor}} interfaces with read, write methods, only to snub
them in the ODataHandler as not valid requests. _Function_ request with _GET_
is functionally equivalent to "read" operations (I get that), but it would have
been cleaner, if it was a _invoke_ to match up to the spec. Although, I do see
PUT, POST, DELETE calls with bound functions, that seems to go against overall
statement "MUST have no observable side effects" for functions. I will try to
get clarification from SPEC leads.
I am failing to see one single advantage to reap out this of this re-factoring
as service developer. Obviously I believe, I am not thinking in same terms as
you have, so pardon me for any obvious omissions. Please let me know.
My thinking more in terms like this, I am not trying to change subject, just
want to provide context to the subject with a quick chalk board.
h2. Response Model
!response_model.png!
The individual response class will have operations/attributes to fullfill the
context of the response type
h2. Request Model
!request_model.png!
The individual requests will have have their state filled with context of the
request like the information from UriInfo etc. to easy access for the
developer. The interrogation of the URI is already being done in the
ODataHandler, we can build the right form requests there.
h2. Processor
!processor.png!
This is the default interface that will handle all requests. Service developers
can override the methods to provide specific request, response flavored
methods. In ODataHandler the code can introspect the Processor interface and
invoke particular method, if method not defined it can forward to the default
method in the above interface. I am sure there may be more tweaks to make, but
that roughly sums up my thinking.
> 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)
