--- 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:53 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, 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.
I call it "Imagine the possibilities..."
>
> (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?
Probably by using an existing Java object to XML conversion library.
> 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.
-Adrian
