--- On Wed, 2/10/10, Adam Heath <[email protected]> wrote: > From: Adam Heath <[email protected]> > Subject: Re: svn commit: r908713 - in > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: > CollectionConverters.java test/MiscTests.java > To: [email protected] > Date: Wednesday, February 10, 2010, 9:19 PM > Adrian Crum wrote: > > --- On Wed, 2/10/10, Adam Heath <[email protected]> > wrote: > >> From: Adam Heath <[email protected]> > >> Subject: Re: svn commit: r908713 - in > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: > CollectionConverters.java test/MiscTests.java > >> To: [email protected] > >> 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"/> -Adrian
