Adrian Crum wrote: > [snip], it had gotten to large, and if anyone needs to refer > back, they can check the list archives, or some such
>> Would it have each nested object get converted to a >> *string*, then >> parse that string back into DOM, and append it to the >> current >> document? Of course not. So, the next way to do >> that might be to >> have a FooToElement type converter. This is >> better. However, each >> FooToElement converter would end up creating a dummy >> document, just to >> create the singleton element that would be representing of >> it's data. >> So, maybe we need to be able to pass down a 'context' >> variable, in >> this specific case, a 'node', to which the converter can >> attach it's >> element. >> >> This would also work well for JSON output, because the >> IndentingWriter >> class could be the context variable that is passed to child >> converters. > > If it was me I would design a JsonString class that hides all of those > implementation details from the conversion framework. I try to avoid feature > envy. ObjectToJSONString, and JSONStringToObject, is fairly straight forward to implement. However, I still need to do my 'resolve' feature. Possibily an ObjectToJSONResolveString, or some such. And, I could get rid of the UtilIO.readObject stuff, by implementing an ObjectToFlatAttribute system.