Hi Rob, I haven't touched this code in quite a while, but I do recall refactoring it while writing the book for the client/server stuff. I didn't change its overall architecture, rather it was more about restructuring it so that the responsibilities were a little clearer and the generated logging a little easier to grok (I wanted to see understand the payloads being sent between client and server). As you say, it's used in a few other places too, most notably Memento. I'm not aware of any bugs in it - there are lots of good unit tests under EncodabilityContractTest - but if there are some, then we should fix it.
In terms of the design of this class, it's pretty much hardwired to writing in binary format, because it's gonna serialize through the provided java.io.DataOutputStream. But the interface it implements, org.apache.isis.core.commons.encoding.DataOutputExtended makes no such assumptions. It seems to me that you could easily write a DataOutputExtendedUsingJson implementation. I think the design of a JSON implementation ought to follow the design of the existing DataOutputStreamExtended, in terms of delegating to its equivalent of FieldType, eg FieldTypeForJson. By the way, we probably ought to rename DataOutputStreamExtended -> DataOutputExtendedUsingBinaryStream, and FieldType to FieldTypeBinary or something similar. But don't do it just yet, please... I'm working on a commit and don't want to get conflicts. HTH, Dan On 24 March 2011 20:19, Robert Matthews <[email protected]> wrote: > Has anyone (specifically Dan) made use of the Memento class and, in > particular, the encode/decode methods? > > What about the DataOutputStreamExtended class and its converse. Is anybody > making use of that? > > I'm not seeing the encoding/decoding work successfully. Dan, maybe we > could discuss its design a bit. I could do ideally with a JSON > representation that could be stored on a web page. > > Rob > > >
