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.

Reply via email to