Hi Hoss, > : 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"
Sure, it's just that it's half-way on both sides right now like you said. There's probably a middle ground. I like the "insulation" but I also understand the "clutter" (i.e., what you're saying). > > : 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. Agreed. Let's document that (implicit) schema so loud people like me don't keep bugging you guys when it's so obvious to you. I'm just trying to help. I'll take an action. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
