On Mon, 2005-10-31 at 16:56 -0800, Eric Johnson wrote: > > The fundamental point, though, is that a bean need not have its own > serialization code - it can be "dumb" to how it actually gets > serialized. If you take that approach, the above question as to whether > you're using a "writer" or a "reader" might be moot. The generated(?) > serialization code can share gobs of functionality and perhaps do both.
The reflective serializers and deserializers do precisely this. Any regular JavaBean can be dealt with this way but of course its slower than if you codegen custom read/write code. > I still like an approach that uses a "writer", rather than a "reader" to > generate the XML. Two particular reasons come to mind: > > * If the point is deferred creation of the XML, that probably also > means deferred reading of the state to be return in a response. I agree that a writer is kinda natural, but this behavior makes me wonder. When I say 'write this object' I don't think the expected behavior is that the state gets snapshotted later, where "later" is an undefined time. So I'd say its the *opposite* that developers would be expecting: that the state that gets serialized is the state of the object when they asked it to be serialized. That argues for the current architecture. Sanjiva.
