Hi together,

>> * Furthermore the JSONEntity and AtomEntity could be merged into a
>>single Entity.
> The only reason why JSONEntityImpl and JSONEntityImpl exist is for usage
with Jackson annotations: as you can see, both barely extend
AbstractEntity.

>> * The use of the Jackson ObjectMapper (in JSON case) seems not
>>necessary. Perhaps the AbstractODataSerializer could use the
>>"JSONEntitySerializer" similar to the "AtomSerializer" (This would also
>>help in merging JSONEntity and AtomEntity by removing the @Json*
>>annotations).
> It seems feasible.

After feedback from Francesco I started with above change but
unfortunately it took more time then expected.
I'am currently in a state in which the common and server parts are changed
(it compiles) but now a lot (client) tests fails because of the changes.

Hence I started with also making changes in the "*Deserialization" parts
to get all work again.
@Francesco: I hope this is no problem for you if with this changes also
some "client" parts are refactored?

I think I will create a "feature/refactore" branch and push all changes as
soon I have a presentable state.
If this is done I write here and ask for more feedback  ;o)

Kind regards,
Michael




On 27.05.14 15:50, "Francesco Chicchiriccò" <ilgro...@apache.org> wrote:

>On 27/05/2014 15:42, Bolz, Michael wrote:
>>Hi together,
>>
>>I started to take a look into the JSON Serialization for the server use
>>case.
>>
>>Therefore I checked the "JSONEntitySerializer" in the commons package
>>and found following points which could be improved:
>>    * The common Entity (JSONEntity and AtomEntity) with the separated
>>Property and Value interfaces is complex and overloaded. Perhaps this
>>could be improved by reducing (merge?) Property and Value to a single
>>class.
>
>Value is also used for instance annotations (via Valuable), here's why
>Property and Value are separated.
>
>>Furthermore the JSONEntity and AtomEntity could be merged into a single
>>Entity.
>
>The only reason why JSONEntityImpl and JSONEntityImpl exist is for usage
>with Jackson annotations: as you can see, both barely extend
>AbstractEntity.
>
>>    * The use of the Jackson ObjectMapper (in JSON case) seems not
>>necessary. Perhaps the AbstractODataSerializer could use the
>>"JSONEntitySerializer" similar to the "AtomSerializer" (This would also
>>help in merging JSONEntity and AtomEntity by removing the @Json*
>>annotations).
>
>It seems feasible.
>
>>And following points are missing but necessary for server usage:
>>    * Use of an existing EDM for type information (instead of setting
>>and/or guessing type like in client use case)
>
>On client-side this is done at higher level, in the ODataBinder
>implementations, when an EdmEnabledODataClient instance is being used,
>as opposite of plain ODataClient.
>
>>    * Differentiation between the metadata output formats
>>"json-full/-minimal/-none"
>>
>>Based on above points I think about the creation of an own JSON
>>Serializer for the server.
>>
>>WDYT?
>
>I don't see any issue with it: only consider that besides client code,
>also the FIT static servers are using the commons (de)serializers.
>
>Regards.
>
>--
>Francesco Chicchiriccò
>
>Tirasa - Open Source Excellence
>http://www.tirasa.net/
>
>Involved at The Apache Software Foundation:
>member, Syncope PMC chair, Cocoon PMC, Olingo PMC
>http://people.apache.org/~ilgrosso/
>
>

Reply via email to