Ahh damn I remember now... in jsonp we have a separate methods to be used
inside objects which takes the key and others without the key, but you
can't first write the key and then write the value...which sucks. I should
have insisted more on that :p
So in short my comment is irrelevant as I was assuming that we have
writeName+writeValue methods in JsonGenerator...so yeah in this case there
is no choice, we need serialize methods that take a key and another that
doesn't... :(
2016-05-09 15:22 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.
>
>
> Agree.
>
> 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.
>
>
> Yes, I think we have some misunderstanding here. Below I copied our latest
> version of SerializationContext interface to make it clear. As you see
> there are no methods for arrays, lists, etc. The method I was talking about
> above is marked bold.
>
> public interface SerializationContext {
>
> /**
> * Serializes arbitrary object to JSON, using current {_at_link
> javax.json.stream.JsonGenerator} instance.
> *
> * @param key JSON key name
> * @param object object to serialize
> * @param generator JSONP generator to serialize with
> * @param <T> Type of serialized object
> */
> <T> void serialize(String key, T object, JsonGenerator generator);
>
>
>
>
>
>
>
>
> * /** * Serializes arbitrary object to JSON, using current {_at_link
> javax.json.stream.JsonGenerator} instance. * * @param object object
> to serialize * @param generator JSONP generator to serialize with *
> @param <T> Type of serialized object */ <T> void serialize(T object,
> JsonGenerator generator);*
>
> /**
> * Converts string value into provided type. String value has to be
> single JSON value, not a part
> * of a JSON document representing JSON object.
> *
> * @param obj object to convert to string
> * @param generator JSONP generator to serialize with
> * @param <T> type of object
> *
> * @return converted string value
> * @throws javax.json.bind.JsonbException if conversion of given type
> is not supported
> */
> <T> String convertDefault(T obj, JsonGenerator generator);
> }
>
> Thanks,
> Dmitry
>
>