2016-05-09 13:31 GMT-07:00 Dmitry Kornilov <dmitry.kornilov_at_oracle.com>:
>
>
> I also think that passing jsonp parser/generator as an argument is OK. The
> question here is that we are forcing implementations to use
> parser/generator. What if (as Romain mentioned somewhere in this thread)
> some implementations will use reader/writer as a parsing mechanism? Shall
> we consider this option? Folks, I need you opinion here.
>
>
JsonReader/writer just deal with the full dom structures, to get a dom
structure one could simply do ctx.deserialize(JsonObject.class, stream).
So I think it is just fine and is the right thing to do: use the low level
jsonp api.
But there is another use case. What if we have a list inside an object we
> are serializing.
>
> public class Create {
> public List items;
> }
>
> For some reason we don’t want to serialize items list using
> context.serialize(“items”, crate.items, generator).
> We want to serialize each item manually in a cycle.
>
> generator.writeStartArray();
> for (Object item in crate.items) {
> // Ooops! We don’t have a method to write an object without a key in
> SerializationContext
> // It should be something like this
> *context.serialize(item, generator); // This is a new method to add I was
> talking about*
> }
> generator.writeEnd();
>
>
Not sure if I followed everything (I have been busy with other things
lately), but IMO the context should not provide different methods for
arrays, objects etc. Only one that takes an object, a generator and
eventually a type (if we want to allow a user to say serialize object of
type B but using his super type A). One could pass to it arrays, lists,
pojos, primitives, whatever he wants and it will get serialized/deser using
the registered serializers for that type.
I hope I am not adding more confusion here...if you want some code examples
let me know.