[
https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240679#comment-14240679
]
Michael Bolz edited comment on OLINGO-482 at 12/10/14 9:58 AM:
---------------------------------------------------------------
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 (as "extends Entity") - *RU* (*CD* inherited)
* EntityCollection - *R*
* Primitive - *RUD*
** PrimitiveValue (as "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*
was (Author: mirbo):
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)
