: > themselves ... because of the back-ass-wards way we have FieldTypes write : > their values directly to an XMLWriter or a TextWriter the idea of using an : > object that stringifies itself as needed doesn't really apply very well : : I think it's rather powerful. You insulate the following variations into 1 : single place to change them (FieldType): : : * output representation : * indexing : * validation : : To remove this from FieldType would be to strew the same functionality : across multiple classes, which doesn't make sense IMHO.
it's a damned-if-you-do/damned-if-you-don't situation though ... you look at as "insulating" the response writers because all of the logic about serializing data is in the FieldType, but i look at it as "poluting" the FieldType with knowledge about the output formats -- there's a reason we didn't add "writeBinary" to the FieldTYpe when the BinaryResponseWriter was added ... the toObject abstraction let's the FieldType do whatever it wants internally, and provide it's "best face" to the world when asked. the ResponseWriters can then apply hueristics to decide the most compatible type they know of to use when representing it: "is it something complex i have a codec for? no; oh well, then is it soemthing that implemnets COllection? no; oh well, then is it something that is an instanceof Number? no; oh well, as a last resort we can stringify" : In the long run, this might be nice, and +1 on getting there in the long : run. In the short, a compromise is to allow namespacing on fields in the : existing XmlWriter, which is allowed anyways, whether by oversight or not. I'm sure if we look hard enough at teh existing internal APIs, we can find a way to generate completley broken XML that no DOM, SAX or pull parser could possibly deal with cleanly -- but that doesn't mean we should do that just because it would allow us to start outputing a bunch of metadata that we think is useful. breaking the (implicit) XML Schema is just as bad as breaking the XML itself. -Hoss
