On Feb 10, 2010, at 11:53 PM, Adam Heath wrote:
> Adrian Crum wrote:
>> --- On Wed, 2/10/10, Adam Heath <doo...@brainfood.com> wrote:
>>> From: Adam Heath <doo...@brainfood.com>
>>> Subject: Re: svn commit: r908713 - in
>>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>>> CollectionConverters.java test/MiscTests.java
>>> To: dev@ofbiz.apache.org
>>> Date: Wednesday, February 10, 2010, 9:19 PM
>>> Adrian Crum wrote:
>>>> --- On Wed, 2/10/10, Adam Heath <doo...@brainfood.com>
>>> wrote:
>>>>> From: Adam Heath <doo...@brainfood.com>
>>>>> Subject: Re: svn commit: r908713 - in
>>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>>> CollectionConverters.java test/MiscTests.java
>>>>> To: dev@ofbiz.apache.org
>>>>> Date: Wednesday, February 10, 2010, 7:05 PM
>>>>> Adrian Crum wrote:
>>>>>> Every programmer has their own design style.
>>> This
>>>>> would be mine:
>>>>>> class JsonString {
>>>>>> public String toString() {
>>>>>> ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> public static class ListToJsonString<T>
>>> extends
>>>>> AbstractConverter<List<T>, JsonString>
>>> {
>>>>>> public ListToJsonString() {
>>>>>> super(List.class,
>>> JsonString
>>>>> .class);
>>>>>> }
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> The problem I have with your approach is the
>>> fact that
>>>>> there is no way to know that converting object x
>>> to a String
>>>>> will result in a JSON string. In addition, I was
>>> hoping we
>>>>> could stick to this pattern: Converting any Java
>>> type to a
>>>>> String is the same as calling the object's
>>> toString()
>>>>> method.
>>>>>> -Adrian
>>>>> Yeah, I thought you would comment on this.
>>>>>
>>>>> Should ListToString and StringToList be
>>> reflective?
>>>>> As they used to
>>>>> be, they weren't.
>>>> That's a good question. The original List conversions
>>> were copied from the ObjectType code and I never looked into
>>> that code in detail - I just wanted to maintain the original
>>> behavior.
>>>> When I picture java types being converted to strings,
>>> I imagine them being displayed - kind of like how they would
>>> appear if you did something like:
>>>> String prompt = "The List is: " + someList;
>>>>
>>>> Making the converters reflective is a worthwhile goal
>>> - I just never considered it.
>>>> What you're trying to accomplish is great. We can take
>>> that concept even further by having type x to XML converters
>>> - so that java objects can be serialized to XML.
>>>> So, that's why I commented on it. What if I wanted to
>>> convert a List to an XML string? Or a [insert encoding
>>> method here] string?
>>>
>>> Here's a summary of what you have said, and what I have
>>> been thinking:
>>>
>>> 1: I've got an object, I want to convert it for
>>> display. This could
>>> call to string, or something else, maybe multiple
>>> converters in series.
>>>
>>> 2: I want to change the format of an object; an object is
>>> nothing
>>> without the data it encapsulates, and there are different
>>> ways of
>>> encapsulating said data. So, converting a
>>> List<Map> to JSON, still
>>> ends up carrying the exact same set of data. This is
>>> simliar to
>>> serialization, but hopefully allows for a human to edit the
>>> converted
>>> state.
>>>
>>> 3: JSON kinda has a hard-coded registry; it can only handle
>>> very
>>> simple basic types. If it was made to use a large
>>> registry of
>>> converters, it would need to have the basic types use the
>>> internal
>>> json, but then all other types use the resolve() syntax.
>>>
>>> 4: XML output is similiar to JSON, but there are no
>>> intrinsic types,
>>> so there doesn't have to be any special casing.
>>>
>>> What this is saying to me, is we need a third parameter to
>>> this
>>> conversion framework; first is source class, second is
>>> target class,
>>> and third would be maybe 'flavor' or 'method'. Method
>>> as in
>>> request.METHOD, or output method, or some such.
>>
>> Nope, we need separate converters:
>>
>> <set field="listAsJsonString" from-field="someList" type="JsonString"/>
>> <set field="listAsXmlString" from-field="someList" type="XmlString"/>
>> <set field="listAsFooString" from-field="someList" type="FooString"/>
>
> Stop thinking top level.
>
> (borrowing json syntax)
>
> {"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
>
> In your example, "someList" is equal to the above example object. But
> then the method that is doing the encoding(JsonString, XmlString,
> FooString) will *itself* call *back* into Converters, asking for a
> conversion for the embed String keys, the embeded list, and the
> embedded map. Then, for the list and map, they too will have to again
> call into Converters, asking for each number and String to be encoded.
>
> What I am suggesting is getting rid of the else if block in
> JSONWriter, *and* the hard-coded xml serialization stuff, and just
> making that *all* use Converters as it's registry.
>
> Hmm, I was going to write more here, but then I realized something
> else. While keeping the above 2 paragraphs is useful, what I am about
> to suggest is an even more radical approach.
>
> If the supposed xml converter existed, how would it actually function?
> 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.
>
> Even doing a normal FooToString converter could make use of this, by
> passing a StringBuilder around.
Keep in mind that Adrian's goal is to do all conversions through polymorphism.
Whether or not that's the best approach is another question (I obviously don't
agree, or I would have written in that way in the first place, or rewritten it
that way, or at least responded to Adrian's commits with a high-five email). Of
course, I'm not convinced I'm always right, so I'll let Adrian have his fun
with this one and see how it goes... either way I hope he "finishes" it soon so
we can get rid of certain error messages that didn't used to be there and such.
-David
