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