Custom field handler

[GoogleCodeExporter]

I have a problem in need of a solution.  I don't think that there is a
"easy" way to do this in gson (there is a "hard" way).

A little about the problem I am trying to solve.  I am using BDB and have a
few entities stored in the database. A few have key relationships that
might be nice to optionally bridge.  For example given the two classes:
class A {
 @PrimaryKey
 String key;
 @SecondaryKey(relatedEntity=B.class)
 String bKey;
}
class B {
 @PrimaryKey
 String key;
}

If I serialize an instance of A it would be nice to have the option to
include the referenced instance of B in the serialized representation. 
Currently the best option is to write a custom serializer for each entity
object that handles this.  This is the "hard" option.  This requires me to
hand code a lot of stuff that gson gives me for free.

The "easier" option that I have thought of (though I am open to
suggestions) would be to have a way to get a callback on serialization when
Gson is at a field with some marker (say a annotation).  From this callback
I could get a hold of the field in need of serialization, and the object
under serialization.  This would then allow me to serialize the field
normally (keeping the key - say the depth is far enough) or to substitute
the referenced entity into the serialized location.  The awkward part of
this approach is that there is no good analog for the deserialization side.

Consider this a long winded enhancement request :) unless there comes a
better option.  ~Brian

Original issue reported on code.google.com by nairb...@gmail.com on 18 May 2009 at 3:46

[GoogleCodeExporter]

Let us get a bit more concrete here. What would that annotation be? I presume 
something like: 

@Callback
long myfield;

However, now this Callback needs a callback method specification. How is that 
callback method specified? One way would be: 
@Callback(callBackClass = MyCallBack.class)

where the expectation will be that MyCallBack will implement an interface that 
is 
invoked during serialization or deserialization. That interface will probably 
look 
very similar to JsonSerializer or JsonDeserializer interface. But then we 
haven't 
achieved much compared to your other "hard" way of doing this. 

Any comments?

Original comment by inder123 on 19 May 2009 at 5:30

[GoogleCodeExporter]

I was thinking something where the annotation is user specified. Example 
follows. The
only problem is when you register SomeAnnotation, and AnotherAnnotation and 
they both
show up on the same field, which goes first? First to register?

interface AnnotatedFieldHandler {
    /** The object, at the this field has the given value in some context. Please
translate/mutate/substitute and return. This could be passed to another 
handler, or
be serialized if not a JsonElement (or subclass thereof) */
    Object handle(Object object, Field field, Object value, SomeContext context);
}

class AHandler implements AnnotatedFieldHandler {
    public Object handle(final Object object, final Field field, final Object value,
final SomeContext context) {
        // make magic happen
    }
}

class ToSerialize {
    private int notTouched;
    @SomeAnnotation private String foreignKeyA;
    @AnotherAnnotation private String foreignKeyB;
}

public static void main(final String args[]) {
    new GsonBuilder().registerAnnotatedFieldHandler(SomeAnnotation.class, new
AHandler()).registerAnnotatedFieldHandler(AnotherAnnotation.class, new
ADifferentHandler())...;
}

This was the shoot from the hip solution that I had.  My fear with this is that
checking every field for a annotation like this can be a potential performance 
issue
and I would hate to introduce that.  In a way my thought was to give the 
ability to
do substitution at serialization of individual fields.  I will be the first to 
admit
it does nto feel like the optimal solution. 
http://code.google.com/p/google-gson/issues/detail?id=43 may be another avenue 
as it
saves form hand writing the whole serialization code by hand (which can be 
error prone).

Thoughts?

Original comment by nairb...@gmail.com on 19 May 2009 at 9:08

[GoogleCodeExporter]

I agree with your assessment. We do plan to fix Issue 43 soon, so that will 
help in 
this. I am closing this bug for now.

Original comment by inder123 on 20 May 2009 at 6:01

• Changed state: WontFix