--- On Sat, 2/13/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: Saturday, February 13, 2010, 10:26 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: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.
>
> Hmm, I've just done this locally. I've changed the
> ListToString and
> MapToString converters back to calling toString.
>
> I finally decided to do this, when I noticed exceptions in
> a test run;
> they didn't fail the test, as the code just ended up
> falling back into
> ObjectType, but it didn't sit well with me.
>
> I still need to do a JSONString->Foo converter, but at
> least I'm happy
> with this, and it's what you suggested.
>
> Currently, I have 15 separate patches queued, mostly all
> going to the
> conversion system, almost all ready to go, implementing
> what we have
> discussesd the pass 2 days. All while maintaining 13
> other patches
> from the commons-vfs/cow stuff, that I am importing from
> webslinger.
I'm working on the same concept here only with XML. I'm created an XML class
that represents and XML object. If you want an XML string, you call
XML.toString(). If you want a DOM object, you call XML.toDOM(). If you want to
deserialize an object, you call XML.toObject().
