Make UUID a known type . I mean add a new type to NamedListCodec. This means bumping up the version of javabin format say version=2. I guess we should not make this change unless we wish to make some more important changes.
but the crux of the issue isn't specific to UUIDField ... any custom FieldType people might have is going to encounter this same problem.
If a RequestHandler adds an arbitrary object (not on the legal list) directly to the response, then the ResponseWriter is certainly at liberty to output that however it makes sense – for both XmlResponseWriter and BinaryResponseWriter that's going to result in a java.util.UUID object, or a chrish.custom.MyBean object, named 'val' being translated into a string via...
val.getClass().getName() + ':' + val.toString()
...that's fine. But the problem seems to be specifically related to how the BinaryResponseWriter deals with writing out field values of Documents – the FieldType should be used to decide how to render field values.
If we want to have optimized code in the NamedListCodec for efficiently dealing with the really commons types that's great, but that fallback case, for dealing with FieldTypes we haven't optimized – that needs to result in the client getting some object which isn't just val.getClass().getName() + ':' + val.toString() ... at a minimum it should be val.toString() , but ideally the FieldType should be able to control of how clients ultimately get the value of that field. (They don't necessarily need to be able to control how it should go over the wire, but they should be able to control what the end result is)
Let's fix the problem (BinaryResponseWriter and field values of arbitrary FieldTypes) and not the symptom (UUIDFIeld)
How exactly we do this ... i'm not sure. Based on my limited understanding of the existing code my rough suggestions...
- NamedListCodec could have pass a special TextResponseWriter subclass to the FieldType's write(TextResponseWriter,...) method, and that TextResponseWriter could take the same special action NamedListCodec currently takes to efficiently serialize all of the datatypes in the varies write*(..) methods
- NamedListCodec maintains it's current list of efficient encodings for common types, but uses FieldType.toExternal() to generate a String to send over the wire (instead of using toObject) in non-common cases.
- we add a new "toSimpleObject(Fieldable)" method to FieldType, which would be documented to say that it must return an object of the "legal" types for a response ... the default implementation would call toObject(Fieldable), test the result with a few instanceOf checks and return val.toString() if it doesn't pass any of them. and start using this method instead of toObject(Fieldable) when dealing with DocLists.