On 03/06/2014 10:48, Bolz, Michael wrote:
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?
As long as all unit tests and integration tests under fit still succeed,
no problems at all.
I would also say that any API change should be prior discussed, instead.
I think I will create a "feature/refactore" branch and push all changes as
soon I have a presentable state.
+1
If this is done I write here and ask for more feedback ;o)
Fine.
Regards.
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/
