[jira] [Commented] (OLINGO-482) Refactoring of {{Processor}} interfaces

["Michael Bolz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240679#comment-14240679 ] 

Michael Bolz commented on OLINGO-482:
-------------------------------------

Hi [~rareddy],

sorry for the delay, but actual I'am back on this issue.

To your mentioned point, IMHO Olingo is a library and not a framework. So the interfaces are the first entry point (after content negotiation and dispatching to a processor) for a developer. Afterwards a developer can decide if he either wants to e.g. do serialization by himself or to use the by the library provided e.g. {{ODataJsonSerializer}} via the {{odata..createSerializer(format)}} method (provided by {{Processor.init(...)}} method).
And for _context url_ we should create (or expose) an according {{ContextUrlHelper}}.

Actual current e.g. _read methods_ are not so far from your suggestion:
{code}
  void readEntityCollection(ODataRequest request, ODataResponse response, UriInfo uriInfo, ContentType responseFormat)
      throws ODataApplicationException, SerializerException;
{code}
Main difference is that we use the pattern like in _Servlet_ handling to pass the {{request}} and {{response}} as parameters (instead of returning the {{response}}).

In addition to my opinion I suggest below _Processor Interfaces_.
During the day I will commit a first change of currently existing interfaces (missing some new methods which actual only would throw a {{NotImplementedException}}).
Think this will make discussion a bit easier (at least for me  ;o)

Kind regards,
Michael

  h2. Processor Interfaces:
  * ServiceDocument - *R*
  * Metadata - *R*
  * Error - *Process*
  * Batch - *Process*
  * Entity - *CRUD*
  ** MediaEntity (als "extends Entity") - *RU* (*CD* inherited)
  * EntityCollection - *R*
  * Primitive - *RUD*
  ** PrimitiveValue (als "extends Primitive") - *RU* (*D* inherited)
  * PrimitiveCollection - *RUD*
  * Complex - *RUD*
  * ComplexCollection - *RUD*
  * CountEntityCollection - *R*
  * CountPrimitiveCollection - *R*
  * CountComplexCollection - *R*
  * Reference - *CRUD*
  * ReferenceCollection - *R*
  * Difference (Delta/Tombstone) - *R*

> 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)